Re: The whole redis/redict/valkey forking situation
On Apr 18, 2024, at 5:19 PM, Eric Gallager via macports-users wrote: > This presents a number of questions for what will happen in MacPorts? It's easy to think of MacPorts as some monolithic organization, but the reality is the answers to your questions are mostly "these things will happen if there is a maintainer who is willing to volunteer to make it happen, and won't if there isn't" > - Will MacPorts continue to maintain a redis port? > - Will MacPorts add ports for valkey and/or redict? > - If so, will the 3 conflict, or will they all be installable separately? > - For ports that currently depend on redis, will they continue to > require redis specifically, or will it be possible to use valkey > and/or redict to satisfy their dependencies instead? > - Do any new licenses need to be added to MacPorts' list of recognized > licenses in response to this change? And does > port_binary_distributable.tcl work properly with the new license(s)? There are special pseudo-licenses available for maintainers to select if the specific license isn't understood by MacPorts itself (so you can effectively tell MacPorts which decision it should make for distributing built software based on the license even if it has some license that no one has ever heard of or thought of before). -- Daniel J. Luke
Re: Idiomatic process for handling needed external language modules for which there is no port
On Dec 15, 2023, at 11:57 PM, Kenneth Wolcott wrote:
> Scenario A:
>
> 1. Install Perl from MacPorts.
> 2. Need Perl module XYZ.
> 3. Perl module XYZ does not exist on MaqcPorts.
> 4. Install (using CPAN, CPANm, or manually) the XYX module locating it
> under the MacPorts port.
> 5. MacPorts complains about things installed under /opt/local that it
> didn't put there (makes sense).
Do you have specifics here?
MacPorts installs perl modules into the vendor_perl directory, if you install
manually it should default to the site_perl directory. You can examine @INC to
see where perl will look for modules (and even adjust it if you want -
https://perldoc.perl.org/perlvar#@INC )
% /opt/local/bin/perl -e 'print join("\n", @INC)."\n";'
/opt/local/lib/perl5/site_perl/5.34/darwin-thread-multi-2level
/opt/local/lib/perl5/site_perl/5.34
/opt/local/lib/perl5/vendor_perl/5.34/darwin-thread-multi-2level
/opt/local/lib/perl5/vendor_perl/5.34
/opt/local/lib/perl5/5.34/darwin-thread-multi-2level
/opt/local/lib/perl5/5.34
You can have conflicts for modules that install things into $prefix/bin, or
similar, though. Using local::lib (https://metacpan.org/pod/local::lib) is a
nice way of handling things if you want to be sure not to conflict with a perl
install (or have different projects that each need conflicting sets of
libraries). It's pretty rare in the perl world for there to be a situation
where you'd need module version A for one project and module version B for
another project (most modules do a good job of backwards compatibility).
> Scenario B:
> 1. Install Perl from MacPorts.
> 2. Perl script I want to use requires a more recent version of Perl
> than those found on MacPorts.
> 3. Install my own version of Perl (usually from source).
> 4. Need Perl module XYZ.
> 5. Install Perl module XYZ (trying to match it with my own install
> location, but frequently screw this up).
> 6. End up with weird path issues, Perl and/or module(s) all confused.
I don't think anything can make it so you don't have to understand which perl
install and which modules you are using.
> Scenario C:
> 1. Install Perl from MacPorts.
> 2. Install Perl from perlbrew.
> 3. Run into problems with #3-6 from Scenario B.
This is how I normally handle things - let Macports' perl be just for things in
MacPorts that need perl and otherwise pretend it isn't there. Use perlbrew to
select the perl install that I want to use, setup my shell to use perlbrew (so
typing 'perl' gets my my perlbrew perl) and set an appropriate #! in my scripts
to use that same perl. [I actually create a perlbrew alias that I put in my
scripts so that I can re-point it to a newer perl if/when I upgrade]
> Scenario D:
> 1 Use a Docker container for Perl exclusively for these experiments
> that I'm trying to use Perl for (various math learning, etc);
> 2. Install Perl from source
> 3. Install all needed external Perl modules myself on the Docker container.
>
> Looks like I end up using Scenario D for Perl and Raku. Now
> considering this for Julia, Python, Rust, etc
containers for everything is the modern way of solving this problem. I mostly
hate it (it's the new static-linking) but it can be pretty convenient
--
Daniel J. Luke
Re: net-snmp runtime problems on Sonoma
On Nov 27, 2023, at 12:17 PM, Daniel J. Luke wrote: > I thought I'd ping the list before digging more into this, but on one Sonoma > (14.1.1) host that I monitor via snmp, MacPorts (and apple's) snmpd (from > net-snmp) seems to get stuck using 100% of one cpu core when I walk the host > (or query some stuff from HOST-RESOURCES, probably .1.3.6.1.4.1.2021.4.3 or > .1.3.6.1.4.1.2021.4.4). > > If I run under lldb and catch it in time (or if I sample it) I see it's stuck > in vm_region_64 (called from pages_swapped)... It's only happening on one > host I'm monitoring, though. Just wondering if anyone else has seen this? For the list archives - this appears to have fixed itself with no intervention from me - which makes me suspect that I've got some hardware that is on its way out. -- Daniel J. Luke
net-snmp runtime problems on Sonoma
Hi, I thought I'd ping the list before digging more into this, but on one Sonoma (14.1.1) host that I monitor via snmp, MacPorts (and apple's) snmpd (from net-snmp) seems to get stuck using 100% of one cpu core when I walk the host (or query some stuff from HOST-RESOURCES, probably .1.3.6.1.4.1.2021.4.3 or .1.3.6.1.4.1.2021.4.4). If I run under lldb and catch it in time (or if I sample it) I see it's stuck in vm_region_64 (called from pages_swapped)... It's only happening on one host I'm monitoring, though. Just wondering if anyone else has seen this? Thanks. -- Daniel J. Luke
Re: Apple Silicon Hardware and MacPorts
On Nov 14, 2023, at 10:04 PM, Alexander Newman via macports-users wrote: > Are large-ish MacPorts ports going to compile all right on a 24 MB RAM iMac > with, say, a 2TB SSD, without the hardware throttling? The same with running > R. Do many people on this list use AS machines, and what are their > experiences and advice regarding MacPorts on them? Am I in fact over-thinking > it? I'll let others chime in for the specific ports you mentioned (as I don't use them) - but for reference I have an M1Pro/16G MacBook Pro and macports + all the ports I care about work fine on it (and it's quite a bit more responsive than my 2018 mac mini). -- Daniel J. Luke
Re: syslog()
On Jun 12, 2023, at 7:59 AM, raf via macports-users
wrote:
> Thanks, Daniel. It's wierd that plenty of logs are
> going into /var/log/system.log, just not the ones I try
> to send via logger/syslog(). :-)
IIRC stuff that was linked against older systems still sends syslogs through
asl and they'd end up in those logfiles like you'd exepct.
> The log(1) manual entry doesn't mention "auth"
> anywhere, and the only mention of syslog is as an
> output format, not as a source. Can you suggest a log
> command that will show syslog auth.{err,info} messages?
> Or do I have to read the Predicate Programming Guide to
> work it out? :-) [Rhetorical]
I don't think the unified logging stuff has a direct translation for classic
syslogd, so there's not really an auth.{err,info}
I usually start with something like
`log show --info --style syslog --last 24h --predicate 'processImagePath
contains "foo"'` or
`log show --info --style syslog --last 24h --predicate 'eventMessage contains
"bar"'`
... and adjust it until I get the data I want.
> What I'd really like is a command to tell the logging
> system to send auth.* syslog messages to
> /var/log/system.log (or better still
> /var/log/auth.log). I probably won't get what I want,
> but the log command above is very helpful.
There's not a way to do that directly. You can run a copy of 'log' and stream
the output to a file.
> But it's less than ideal with my program which sets the
> syslog program name to "sshdo", but the logging system
> seems to just discard that information (and the syslog
> facility). Instead, it uses "Python" as the program
> name (because sshdo is a python script).
Yep, I've had this same problem - for most things I just ended up switching
them to not use syslog API.
Mostly I accept that MacOS logging is it's own thing now and I'm happier if I
don't expect it to work like a normal unix box.
--
Daniel J. Luke
Re: syslog()
On Jun 12, 2023, at 12:39 AM, raf via macports-users wrote: > Does anyone known where auth.* logs end up? Or if they don't end up > anywhere, is there a way to make them go somewhere? syslog stuff has changed a few times with MacOS .. I think the asl stuff stopped being default in ~ 10.12. You should be able to see the logs with `log stream --style syslog` (you can do filtering to get it to just show you the messages you care about). -- Daniel J. Luke
Re: [openssh: segmentation fault]
It's probably this bug: https://trac.macports.org/ticket/67539 I imagine there will be an update to the port to work around the issue soon. > On Jun 8, 2023, at 12:27 PM, Maxim Abalenkov > wrote: > > Dear Fabien, > > Thank you for your suggestion. I tried to remove the duplicates and > temporarily renaming the ‘known_hosts’ into ‘known_hosts.old’, but I still > experience the same issue. > > — > Best wishes, > Maxim > > Maxim Abalenkov \\ maxim.abalen...@gmail.com > +44 7 486 486 505 \\ www.maxim.abalenkov.uk > >> On 8 Jun 2023, at 13:37, Fabien Auréjac wrote: >> >> Some say in Apple forums to clean known_hosts and known_hosts2 files by >> removing all the duplicates... >> Will this be helpful for you ? >> Le 08/06/2023 à 14:28, Maxim Abalenkov a écrit : >>> Dear all, >>> >>> How are you? I hope all is well with you. I need help please. This morning >>> I ran into an issue of being unable to pull the latest changes from a >>> GitLab repository. I checked the SSH keys, the URL and .ssh/config file. >>> These appear to be correct. On the other hand, I notice that when I run >>> pure ‘ssh’ command in a terminal it crashes with a ‘segmentation fault 11’. >>> I tried re-installing openssh port. But it didn’t help. Would you please >>> help me to debug this issue? Do I miss something obvious? Thank you and >>> have a good day ahead! >>> >>> — >>> Best wishes, >>> Maxim >>> >>> Maxim Abalenkov \\ maxim.abalen...@gmail.com >>> +44 7 486 486 505 \\ www.maxim.abalenkov.uk > -- Daniel J. Luke
Re: Big Sur on M1 - bind9 named daemon don't run
> On Sep 22, 2022, at 8:56 AM, Mark Lucas wrote: > I just updated to bind 9.18.7 (Intel mac mini - macOS 12.6 ) and despite > checking the config was ok, which it was, bind refuses to start. > Looking at the contents of /opt/local/var/named/ mysteriously most of the > files were now listed as being owned by non existent user 511. > e.g. -rw-r--r-- 1 511named - 3.2K 4 Aug 2021 named.root > Tried uninstalling and reinstalling bind9 and changing /opt/local/var/named/ > files owner to named but the problem remains. I think the permissions stuff is unrelated to the port - it only installs these files into /opt/local/var/named: % port contents bind9 | grep /opt/local/var/named /opt/local/var/named/db.127.0.0.dist /opt/local/var/named/db.cache.dist /opt/local/var/named/db.localhost.dist You can try to start named by hand with `-g` (and maybe add a -d # option) to try to get more information on why it's not starting for you. -- Daniel J. Luke
Re: Big Sur on M1 - bind9 named daemon don't run
On Aug 31, 2021, at 8:52 AM, FritzS GMX wrote: >>> But the named daemon don't run. >>> >>> All this commands don’t work: >>> >>> sudo launchctl load -wF /Library/LaunchDaemons/org.macports.bind9.plist >>> >>> sudo /opt/local/bin/port load bind9 >>> >>> sudo /opt/local/sbin/rndc reload >>> >>> What must I do that the named daemon runs? >> >> Why don't the above commands work? What happens? > > No, there are no inputs in the own bind9 logging files, no logging files > available. (sorry for the necro-thread) - I saw similar behavior today (with bind 9.18.7), no logging, no debug output from named. Under the debugger I could see that there's a fork() and the parent doesn't get the response it expects from the child and so terminates. A little more digging showed me that my previously valid named.conf was now invalid (named-checkconf was able to point out exactly the problem). I updated named.conf and things are working as expected. Just something to look at if you (or anyone looking at the list archive) sees random failures like above. It's really too bad that named doesn't generate some output to at least point you in the right direction for this case. -- Daniel J. Luke
Re: x86_64 version of libncurses; libintl
On Aug 31, 2022, at 9:36 AM, Murray Eisenberg wrote: > dyld[3024]: Library not loaded: '/opt/local/lib/libintl.8.dylib' > Referenced from: '/usr/local/bin/bash' > Reason: tried: '/opt/local/lib/libintl.8.dylib' (mach-o file, but is an > incompatible architecture (have (arm64), need (x86_64))), > '/usr/local/lib/libintl.8.dylib' (no such file), '/usr/lib/libintl.8.dylib' > (no such file) > /usr/local/bin/sage: line 20: 3024 Abort trap: 6 /usr/bin/env - > PATH="$PATH" $MIN_ENV "$SYMLINK"/venv/bin/sage "$@" > > I find no port named libintl or intl available. But there are available ports > with “libintl” as part of their names, e.g., phpxx-intl, py-elib.intl, > p5.30-libintl-perl. > > I haven’t a clue as to which of those to try! You can use `port provides` to figure out which port an installed file is from: % port provides /opt/local/lib/libintl.8.dylib /opt/local/lib/libintl.8.dylib is provided by: gettext-runtime -- Daniel J. Luke
Re: jemalloc +universal
On Aug 22, 2022, at 1:31 PM, Bill Cole wrote: > On 2022-08-22 at 10:26:14 UTC-0400 (Mon, 22 Aug 2022 15:26:14 +0100) >> The auto build build either an arm64 or an x86_64, so seems like no one >> would ever know if a +universal build fails. > > It's unclear to me why anyone would need a universal build for something so > low-level. Looking *cursorily* at the errors in the log in your bug report, I > suspect it may be due to the code not having support for a universal build. > You may want to also open an upstream bug, if you can analyze it well enough > to determine that upstream fixes are required. the muniversal portgroup may help here (since it will just run multiple builds and lipo them together), but I haven't looked at the jemalloc build to see if it would be helpful here (sometimes the build changes needed make it easier to just make the project build universal the 'normal' way instead). -- Daniel J. Luke
Re: MacPorts bind9 dig not working correctly
The bind9 port doesn't patch this behavior (if you look at the port, there's a configure patch because upstream uses broken glibtool and an atomics patch to allow building w/ older clang versions), so it's almost certainly due to an upstream change. > On Jun 26, 2022, at 8:23 AM, Larry Stone wrote: > Good observation. Still, what the MacPorts version of dig is doing is not the > default (or at least hasn’t been (see next paragraph) as I mentioned in my > first post, I used to build BIND from source). > > But one other thought I just had is it’s a change with the latest version of > BIND. The Apple provided dig is old enough that it must be BIND 9.16 and the > source-built version I tested with is also from the 9.16 tree. But the > MacPorts version is from the new 9.18 tree. Unfortunately, I no longer have a > source-built 9.18 copy of dig to test with. -- Daniel J. Luke
Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?
On May 22, 2022, at 5:32 AM, Ryan Schmidt wrote: > It is possible but not permitted to specify "the latest code" (such as a > Subversion repository trunk or a git repository main or master branch or the > head of any branch in any revision control system in fact) because if you did > that, what one user received when they installed the port at one moment in > time would be different from what another user received if they installed it > at a different moment in time if there had been commits to that branch of the > repository between those two moments in time, but MacPorts would not convey > that difference in the output of "port installed", nor would "port outdated" > convey to the user who installed the port first that any update were > available. If the port is distributable, users would receive even older > versions of the software from whenever the buildbot first built it. +1 for this We'd not want such a port in the man repository, but in Bill's case, it would be reasonable for him to do this locally... Macports wouldn't know that the trunk (or whatever branch) had been updated, so he'd need to manually rebuild - but that seems like something manageable for just using MacPorts for nice reproducible(ish) builds + easy cleanup of temporary versions. -- Daniel J. Luke
Re: How do people use ManageSieve on macOS
On Feb 19, 2022, at 9:19 AM, Gerben Wierda via macports-users wrote: > How do people use this from their macOS clients? For this, the ManageSieve > protocol exists and this is implemented by dovecot-sieve, but other than > installing roundcube and offering a web-based mail client that also supports > ManageSieve, is there another way? A ManageSieve client that directly runs on > the macOS client and interfaces with dovecot-sieve on the server? For my small mailserver, I've got RoundCube setup + a few people have shell access and can edit stuff by hand if they like. This way I don't have to expose the ManageSieve port directly to the world (although it would probably be fine). In practice, I setup a default ruleset and almost everyone just uses that. http://sieve.info/clients has a list of clients that can use ManageSieve. -- Daniel J. Luke
Re: "Broken files found, but all associated ports are not in the index" error
On Dec 16, 2021, at 6:08 PM, Ryan Schmidt wrote: >> Is there anything I can do about it? I still have a ton of p5.26-* and >> p5.28-* ports installed, as well as p5.30-*. > > I recommend uninstalling all p5.26 ports. Use p5.28 equivalents instead. Unfortunately, this cleanup is necessary because MacPorts has decided to support multiple versions of perl5 (which I think is a bad choice). If MacPorts instead had a perl5 port that tracked the latest perl5, the end-use experience would be 'port upgrade outdated' and everything could continue to work (provided we bumped the revision of all of the p5- ports and/or added some update to base or to a portgroup to make that unnecessary). Instead you need to periodically uninstall any p5.XX ports and older perl5 - install equivalent newer perl5 and p5.XX ports that you want to use directly ... and /also/ find any ports that you have installed that use a variant to specify which perl5 version they want and uninstall + reinstall them with the new variant that points to the newer perl5 that you want. It's enough effort that I, personally, don't use MacPorts perl for anything other than MacPorts dependencies - and instead use perlbrew to manage a perl install for any of my stuff that uses perl. -- Daniel J. Luke
Re: Can some ports install config files inside '/usr/local/etc'?
On Dec 11, 2021, at 12:11 AM, fgyamauti2 fgyamauti2 wrote: > Apparently some ports that I've installed are making directories inside > '/usr/local/etc' with example configuration files. Still the installed ports > themselves seem to only listen to stuff inside '/opt/local/etc'. They shouldn't be. > For instance, I have an 'unbound' folder inside both. In the former, it > contains 'unbound.config', while in the latter it contains 'root.key' and > 'unsound.config-dist' (a file with contents identical to 'unbound.config'). > That seems to happen to particular ports only, though. Anyone experiencing > that? Are these folders really unnecessary? On my system(s) the unbound port does not create anything in /usr/local/etc `port contents unbound` doesn't show any unusual files and I don't see any part of the portfile that would be doing that on your system. -- Daniel J. Luke
Re: clang config issue
On Oct 27, 2021, at 2:23 PM, William Parducci wrote: > I’m tried to install nmap on a clean install of macports in Big Sur. When it > got to configuring clang it is threw this error: > > configure:2838: /usr/bin/clang -qversion >&5 > clang: error: unknown argument '-qversion', did you mean '--version’? > […] > clang: error: invalid version number in 'MACOSX_DEPLOYMENT_TARGET=11.0’ > […] > configure:2940: error: C compiler cannot create executables > > I see that the nmap configure file is asking for “qversion” > > $ grep qversion > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nmap/nmap/work/nmap-7.92/configure > for ac_option in --version -v -V -qversion; do > for ac_option in --version -v -V -qversion; do > for ac_option in --version -v -V -qversion; do > > I edited the configure file to read --version and it worked > > Full log attached. Can you attach the Macports main.log instead? From your config.log it looks like it actually fails when trying to create a simple executable (after it complains about -qversion) Note that the port seems to build find on Big Sur (https://ports.macports.org/port/nmap/builds/) -- Daniel J. Luke
Re: Aspell port
The aspell port installs a cli tool (as $prefix/bin/aspell) You can see what a port installed by running `port contents portname` (so `port contents aspell`) There's nothing there that would make aspell show up in Mail.app It looks like cocoAspell is what you saw previously. > On Sep 1, 2021, at 6:42 AM, Christoph Kukulies wrote: > > macOS 11.5.2 > > I tried to install the aspell port aspell @0.60.8_1 (textproc) plus > appropiate language packs. > > The port installs but I don’t see any traces of aspell in applications like > Mail.app. > > Any clues? I also experimented using brew and cocoAspell. For a while I saw > German (Aspell) or Deutsch (Aspell) in > but they seem to have disappeared by some action I did, but cannot > reconstruct, what action it was. Maybe removing cocoAspell (?). > > Any help appreciated. TIA. > > Christoph -- Daniel J. Luke
Re: Why don't p5-* ports mark their dependencies?
On Jun 6, 2021, at 1:41 PM, Bill Cole wrote: > I *think* I've even worked out the right way to use that construct to make > Perl upgrades simpler, so I use the p5-* ports: I gave up on trying to use this in any useful way a while ago - if you've got some way that it works, please share. (FWIW, things would 'just work' if we'd ship the current version of perl5 and only have p5-foo ports). For anything outside of MacPorts I recommend using perlbrew and just letting the macports perl install be only for things installed via macports. -- Daniel J. Luke
Re: state of libressl in macports
On May 10, 2021, at 7:30 PM, Ryan Schmidt wrote: >> Is macports as a project going to drop support for libressl? (Several linux >> distros, e.g. gentoo and void, did it recently). >> It would be nice to have libressl in macports, but if the project does not >> have resources to support it, would it be better just to state that >> explicitly? It would prevent unnecessary expectations. > > I don't think anyone's expressed any interest in dropping libressl support > before. I wasn't aware that any Linux distros had dropped support for it, but > I don't know anything else about what Linux distros are doing either. Do you > know why they dropped libressl? A lot of cleanup happend on the openssl side and they're integrating changes more quickly than libressl is now. Since some software requires patches to work with libressl, it's less effort for vendors to just support openssl. Some of the *BSDs (notably OpenBSD) are still using libressl as their default ssl implementation, though, so it doesn't seem like libressl is going to go away. -- Daniel J. Luke
Re: Reclaim was not 'safe'
I agree that the implementation could be better - it doesn't look super-complicated, perhaps making this less surprising/less destructive would be a good first project for someone interested in working on macports-base? > On May 10, 2021, at 3:53 AM, Richard L. Hamilton wrote: > Too late now, but IMO, if it had been three state (tag absent as well as > unrequested and requested values) from the first introduction of that tag, > and automatic assignment of "unrequested" was conservative enough, then one > wouldn't have to tag everything one wanted to keep as requested. In other > words, ports already installed at the time of the introduction of the tag > could have been handled differently from those installed later. Also, some > ports that seem just meta-ports to install a bunch of others (like kdegames4) > should IMO, if explicitly installed, tag all the ports they install that are > not just build-time dependencies as requested (if they don't already - I > don't know when the tag was added, nor when I installed kdegames4). > >> On May 10, 2021, at 01:13, Randal L. Schwartz wrote: >> >>>>>>> "Gerben" == Gerben Wierda via macports-users >>>>>>> writes: >> >> Gerben> That was a mistake I now know. Reclaim will remove active unrequested >> Gerben> installs. But the help/man does not say so. >> >> Let me just say that as a long-time Macports user, I also got burned >> badly by this. -- Daniel J. Luke
Re: Reclaim was not 'safe'
On May 9, 2021, at 12:20 PM, Gerben Wierda via macports-users wrote: > Anyway, the hard lesson was: reclaim is not ’safe’. I thought, reclaim would > only remove inactive installs, but it removed active ones as well. > > It is not possible for me to retrace what went wrong exactly, sadly. The first thing reclaim does is this: ---> Checking for unnecessary unrequested ports Unrequested ports without requested dependents found: If you (like me) have an MacPorts install that pre-dates the requested flag, you'll have a bunch of ports in that list that you don't actually want uninstalled. For reclaim to work best, you need to do `port setrequested` on the ports you want to always keep - then the list of ports you see there will be stuff that got installed that you no longer need. (You can also mark things 'unrequested', see the port manpage - so you can fix things up if you mistakenly mark something requested that you don't want). Or, you can just hit 'n' for the first prompt. -- Daniel J. Luke
Re: Using RAM instead of disk for build servers (was: Re: Build servers offline due to failed SSD)
On Mar 14, 2021, at 6:38 PM, Ryan Schmidt wrote: > As far as longevity, the previous set of 3 500 GB SSDs I bought for these > servers in 2016 lasted 4-5 years. They were rated for 150 TBW (terabytes > written) and actually endured around 450 TBW by the time they failed, or 3 > times as long as they were expected to last. The new SSDs are rated for 300 > TBW, and if they also last 3 times longer than that, then they might last > 8-10 years, by which time we might have completely abandoned Intel-based Macs > and be totally switched over to Apple Silicon hardware and will have no use > for the Xserves anymore. Thanks for including this information - it's similar to experience I've had with SSDs for $work. I'd be really surprised if we care about builds on the xserves in 8-10 years (given our previous experience with the ppc to x86 transition). I haven't looked recently, but I recall xserves being somewhat picky about their internal drives - have you found that specific SSDs work well (vs others that don't)? I'm assuming you've installed them on the internal trays - but maybe that's a bad assumption. -- Daniel J. Luke
Re: Using RAM instead of disk for build servers (was: Re: Build servers offline due to failed SSD)
On Mar 14, 2021, at 6:38 PM, Ryan Schmidt wrote: > As far as longevity, the previous set of 3 500 GB SSDs I bought for these > servers in 2016 lasted 4-5 years. They were rated for 150 TBW (terabytes > written) and actually endured around 450 TBW by the time they failed, or 3 > times as long as they were expected to last. The new SSDs are rated for 300 > TBW, and if they also last 3 times longer than that, then they might last > 8-10 years, by which time we might have completely abandoned Intel-based Macs > and be totally switched over to Apple Silicon hardware and will have no use > for the Xserves anymore. Thanks for including this information - it's similar to experience I've had with SSDs for $work. I'd be really surprised if we care about builds on the xserves in 8-10 years (given our previous experience with the ppc to x86 transition). I haven't looked recently, but I recall xserves being somewhat picky about their internal drives - have you found that specific SSDs work well (vs others that don't)? I'm assuming you've installed them on the internal trays - but maybe that's a bad assumption. -- Daniel J. Luke
Re: Build servers offline due to failed SSD
On Mar 7, 2021, at 8:30 PM, Todd Doucet wrote: > I think one can only get so far with purely qualitative analysis of the > characteristics of SSDs and HDs and then the end of that analysis will be > one-size-fits all advice, for example "recommended" or "not recommended" for > servers. this +1000 > Surely the answer might vary depending on the particular server usage > pattern, the need for performance, the cost of routine maintenance (swapping > out aging drives or SSDs), the cost of the devices themselves, etc. exactly There's a reason you don't really see 15k enterprise drives anymore. > It seems to me that a given server operator can tell how long a particular > SSD is likely to last. They do not fail randomly, at least not very much. > The fail when they are "used up" and you can figure out well in advance, > usually, when you will need to swap the old ones out of service. Back in 2015 - there's this article https://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead/ where someone actually bothered to test and report some results. > HDs fail also, obviously, but tend not to be so predictable about it. > Whether it makes sense for a given server to use an SSD really does depend on > the numbers. All drives will fail. All drives will need to be rotated out > of service. It is a matter of cost, convenience, and performance. > > The only caveat I can think of is that there might be an issue of malicious > use--a server with SSDs might be vulnerable to a wear attack, depending on > the server services offered, I suppose. I'm sure there are worst-case scenarios for spinning disks that (in theory) could be exploited to wear their mechanisms out as well. I've personally used both enterprise and consumer SSDs in high-write environments where the cost of replacing the SSDs was worthwhile for the performance benefits (or otherwise didn't change the overall cost of the solution) - and I've been pleasantly surprised with how much more use I've gotten from them than I originally calculated (based on the drive specs + the planed utilization + over provisioning). YMMV of course - but the blanket "you shouldn't use SSDs for servers" or "no one uses SSDs for servers" is wrong. For those who are interested in more details, there are a bunch of good USENIX and ACM papers where people have actually gone and collected data on real-world failure rates. -- Daniel J. Luke
Re: apache2 IPv6 Big Sur
On Jan 17, 2021, at 7:51 AM, Steve Wardle via macports-users wrote: >> I figured out why this is happening and filed a bug report for you: >> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=65087 >> >> It's a bug in the apr configure script. apr is a library that apache uses. > > Thanks very much for tracking this down and filing the bug. Yes, thanks Ryan - I've updated the upstream bug and pushed a patch (with revbump to apr and apache2) that fixes this. -- Daniel J. Luke
Re: python2.7 throws bus error when issuing `help("modules")'
On Aug 24, 2020, at 6:32 PM, Jeffrey Walton wrote: > Sorry, I have no idea what standard processes Macports adheres to. Yet, you claimed that because of "audit requirements" MacPorts must distribute patches to any software you install via the port command. >> Please explain what the enforcement mechanism is if MacPorts fails this >> imaginary audit (ie, do you get something other than a refund of the $0 you >> paid?). How does this audit compel volunteers to fix an issue for you for >> free? > > $0 means nothing. > > There are no enforcement mechanisms. You could plead to the developer > hoping they will take pride in their workmanship. It is hit or miss > whether it works. Ok, it sounds like your argument is: "MacPorts must provide the patches I wish for because otherwise I will consider them bad developers with no pride in their work" Which I don't think is reasonable, but you're free to consider MacPorts developers good/bad/ugly/pretty or whatever. You're also welcome to advocate for policies that you think are appropriate or, even better, to volunteer to help the project in areas where you feel it is deficient. > Sometimes we find gems, like Botan and cURL, but they are few and far > between. Folks like Jack and Daniel are constantly improving their > processes. When someone finds a gap they try to address it. They don't > say "go talk to someone else" when it affects their project. Here's an example that might make things clearer for you. When you build the apache httpd server, you can choose to link it against the PCRE library. If you report a bug in the PCRE library to the Apache httpd project, they will refer you upstream. You can complain all you want, but it won't force them to patch PCRE to fix the bug you found. >> I'm also curious what imaginary audit wouldn't first point out that >> python2.7 was sunset on January 1, 2020. > > No, the audits folks have to go through are real. Audits are real, MacPorts being required to do something to pass your imaginary audit is not. > A finding on Python 2.7 is irrelevant. What is the point? I guess the irony of you demanding patches for upstream unsupported software because of some vague hand-waving about audits is lost on you. > The most curious responses often come from folks who have never been > exposed to project management, development lifecycles or SDLCs. They > are literally the group that does not know what they don't know. Personal attacks are fun too, I guess. FWIW, I've worked for organizations with lots of formal SDLC process (and organizations with less process). In my experience software quality is inversely proportional to the amount of process (YMMV) - I suspect that this is more to do with organization size than the processes themselves, but I haven't done the necessary research to determine what the actual truth is (Perhaps someone has, it would be interesting to read about a well designed study to investigate this). > I don't believe I have a misunderstanding. Macports is a supplier of > software for OS X. Macports is responsible for the software they > provide. The software that MacPorts provides is the 'port' command. You can choose to use the port command to easily install other software. -- Daniel J. Luke
Re: python2.7 throws bus error when issuing `help("modules")'
On Aug 24, 2020, at 5:41 PM, Jeffrey Walton wrote: >> It's also super-silly to expect that MacPorts is taking "responsibility" for >> all upstream projects. > > How so? > > It is a standard audit item. please cite what "standard" you believe you are auditing MacPorts under. Please explain what the enforcement mechanism is if MacPorts fails this imaginary audit (ie, do you get something other than a refund of the $0 you paid?). How does this audit compel volunteers to fix an issue for you for free? I'm also curious what imaginary audit wouldn't first point out that python2.7 was sunset on January 1, 2020. > You don't get to claim you are using > software X and any problems are someone else's responsibility. I'm pretty sure I can claim whatever I want ;-) > If you > don't want to be responsible for software X, then you don't use it. Ok, so I guess you are also responsible for MacPorts and all of the software that ports exist for because you use it. >> MacPorts is a community-sourced collection of build recipes. It also hosts >> some mirrors for files referenced in those build recipes and the cached >> results of those build recipes. >> >> It's all done by volunteers and if you paid someone for access to them, you >> should follow-up with whomever you paid. > > The only thing super silly is not taking responsibility for it and > then pushing it onto unsuspecting users. I think you misunderstand what MacPorts is. Please re-read the sentence: "MacPorts is a community-sourced collection of build recipes." -- Daniel J. Luke
Re: python2.7 throws bus error when issuing `help("modules")'
On Aug 24, 2020, at 3:49 PM, Ryan Schmidt wrote: > On Aug 24, 2020, at 13:27, Jeffrey Walton wrote: >> On Mon, Aug 24, 2020 at 2:15 PM Ryan Schmidt wrote: >>> ... >>> If you believe PyObjC should do something differently, please take it up >>> with the developers of PyObjC. >> >> Macports is responsible for the code it distributes. It is called >> "supply chain management". > > Well. What I was prepared to do to fix this problem was to apply a patch that > had previously been created by one of our developers, and had been accepted > by the developers of PyObjC. The same code is present in the current PyObjC > distributed by its developers. I'm not prepared to further analyze their code > to understand how it works and to understand your proposal for changing it. > You are welcome to take up any further desired changes with the developers of > PyObjC. If they make any changes that are important to py27 and py35 as well > we can back-port them. It's also super-silly to expect that MacPorts is taking "responsibility" for all upstream projects. MacPorts is a community-sourced collection of build recipes. It also hosts some mirrors for files referenced in those build recipes and the cached results of those build recipes. It's all done by volunteers and if you paid someone for access to them, you should follow-up with whomever you paid. -- Daniel J. Luke
Re: How enable ftp to localhost wordpress site?
I'd strongly recommend you don't use FTP. Use 'sftp' instead (if you've got sshd running on the server you can use sftp). Most of the graphical ftp clients support sftp also. For anyone out there who actually needs ftp, vsftpd is a pretty good choice (but you probably don't actually need ftp, so just use sftp instead). > On Jul 31, 2020, at 8:28 PM, Murray Eisenberg > wrote: > > I’ve installed the MacPorts version of apache2 and have a working localhost > wordpress site running under apache2. > > How to I enable ftp with this, so that I can ftp into the wordpress site? > (This is so I can install WordPress plugins.) > > Is there some particular MacPorts port I need to add? and then what do I need > to do so it’s available from within the wordpress site? > > (WordPress docs don’t deal with this! they just say to use ftp to install the > plugins.) -- Daniel J. Luke
Re: Login shell
On May 7, 2020, at 3:34 PM, Ken Cunningham wrote: >> there are large closed-source surface areas that you aren't going to be able >> to keep updated. > > You have said that before, and I listened, but: > > all my systems live behind a firewall, and none are exposed to the open web. > I don’t use any MacOS-era software to access anything outside the network. > Only, really, MacPorts stuff (all with up-to-date security) and TenFourFox > (also built with MacPorts stuff, also with all up to date security). ... and they're probably all linked with versions of Libsystem that don't have the most recent patches from Apple (you could probably be backporting them, but I doubt you're doing that :) ). > I just don’t see the vulnerability, TBH. > > If you know of any, please give me an example. I don’t want to be stupid > about things. It's risky - the majority of bugs that Apple releases security patches for are in components that exist in previous Mac OS versions. Maybe those versions don't have those problems (but they probably do). Maybe no one is exploiting them. If you are firewalling and monitoring both inbound and outbound traffic, maybe you've set things up so that you can run a vulnerable system safely. Most people aren't capable of doing that. These kinds of things are hard to do well - if you've got a strong perimeter, but vulnerable systems inside - it just takes one problem with your perimeter security and an attacker has access to everything you thought was secured by your perimeter security. > The time daemon, maybe? I heard there was something about that daemon, yeah, it's had a bunch of problems. > but it just checks Apple’s time server. how do you know? (hint: ntp uses udp and also bgp-interdomain routing is still largely insecure). > I could replace that too, I guess... At that point, if you're not using any MacOS software - why are you running Mac OS at all? That hardware can run an OS that's still getting security patches and run all of the unix-y software that's in Macports without the risk. (Of course, Mac OS UI and hardware drivers are generally better, so I understand there may be reasons why people might want to do this - but I think it's too easy to overlook the potential downside). [This is probably off-topic for macports, so I'll refrain from typing more] -- Daniel J. Luke
Re: Login shell
On May 7, 2020, at 2:48 PM, Bill Cole
wrote:
> That looks like my ugly hack. I came up with it shortly after the disclosure
> of the "ShellShock" vulnerability.
>
> The reason to do this when replacing a login shell or (most importantly) the
> system shell at /bin/sh is that you do not want either of those to be
> breakable by modification of a shared library installed by MacPorts.
alternatively, at the time I believe I downloaded the source from Apple,
applied the upstream patch, and replaced the system /bin/sh with the result.
> The primary reason that one should replace /bin/{bash,sh} with a newer
> version on older versions of MacOS X is ShellShock.
People who are running older versions of Mac OS X have chosen not to care about
vulnerabilities - since they're no longer getting security updates from Apple.
While it's maybe possible to patch/replace some of the parts of the system -
there are large closed-source surface areas that you aren't going to be able to
keep updated.
--
Daniel J. Luke
Re: Login shell
On May 7, 2020, at 11:38 AM, Christoph Kukulies wrote: > > I don’t know if that belongs into macports, but I believe a lot of problems > (I currently have) with PATHs may be, that Catalina (?) changed the login > shell from sh (bash) to zsh (or am I wrong with this)? > > Where do I change the users’ lofin shell. Unixwise I would say in > /etc/passwd, but I don’t find any (my) username there. use the 'chsh' command to change your shell. > For instance my anaconda3 installation was totally spoiled after updating to > Catalina. > > For the fun of it I started bash, did a . .bash_profile and started > > conda update —prefix /opt/anaconda3 anaconda > > and lo and behold, I received a smooth update in that window. > > Would the world be better for me if I go back to bash login shell? And why > did Catalina cause such a mess? For my computer, it didn't change my shell - but prints a message telling me that I should. I just installed bash from macports and have it set as my shell :) -- Daniel J. Luke
Re: EXSi
On Apr 6, 2020, at 5:06 PM, Michael wrote: >> Did you try a current version of macOS on top of ESXi? I'd be curious if >> anyone has tested this setup and how is the performance. > > What is ESXi? VMware's hypervisor (you can read more by typing 'ESXi' into google and clicking the first link ;-) ) -- Daniel J. Luke
Re: how to stop variants from propagating down to dependencies
On Dec 31, 2019, at 10:34 AM, Ken Cunningham wrote: > On 2019-12-31, at 7:26 AM, Daniel J. Luke wrote: >>> >>> Except that would get the rdeps of openal-soft with its default variants, >>> rather than with the +gui and +tests variants. >> >> That's what I understood Ken was trying to do. > > I think Ryan means that if the "test" variant of openal-soft had a dep on, > say, ghostscript, you wouldn't get that. You wouldn't get them installed without +gui +test, but you would get them when you installed openal-soft +gui +tests (which ends up being close to what you wanted). > There is just no good way to fix this -- unless we were to decide that a > certain set of named variants, like "tests" or "docs" or "gui" , would not be > propagated down. Or conversely that only a certain set of named variants are > propagated down (like "universal" and -- any others?). > > Probably too much trouble. I think it is - in my mind the correct solution is to just avoid the use of variants wherever it's reasonable. -- Daniel J. Luke
Re: how to stop variants from propagating down to dependencies
On Dec 31, 2019, at 12:59 AM, Ryan Schmidt wrote: >> you could probably do something like port install rdepof:openal-soft && port >> install openal-soft +gui +tests > > Except that would get the rdeps of openal-soft with its default variants, > rather than with the +gui and +tests variants. That's what I understood Ken was trying to do. -- Daniel J. Luke
Re: how to stop variants from propagating down to dependencies
On Dec 30, 2019, at 4:41 PM, Ken Cunningham wrote: > > I thought I would install the new openal-soft with the gui with the tests as > well. > > sudo port -v install openal-soft +gui +tests > > I did not already have cmake or qt5 installed on the 10.7 system I was using. > > Running the above command installed cmake from source with the +gui option, > as no binary exists for that, and then started to install qt5-qtbase with the > +tests variant until I aborted that. > > I installed qt5-qtbase separately, without +tests, using the buildbot binary, > and then when I installed openal-soft +gui +tests I got what I wanted. > > So — I guess there is no way around this automatically? you could probably do something like port install rdepof:openal-soft && port install openal-soft +gui +tests In general, though, it's an intentional feature that variants propagate down like that. It's one of the reasons why it's best to have as few variants as possible in a port. -- Daniel J. Luke
Re: Troubleshooting a bsdtar installed
On Oct 11, 2019, at 11:14 AM, daniel Azuelos wrote: > I entered: > type bsdtar > to discover it is the one located in: > /opt/local/bin/bsdtar > recently installed in my MacPorts tree. > > How may I find which package provoqued this install of "bsdtar"? % port provides /opt/local/bin/bsdtar /opt/local/bin/bsdtar is provided by: libarchive -- Daniel J. Luke
Re: Logging to syslog (by unbound, nsd, etc.) disappearing in a black hole
On Aug 15, 2019, at 2:53 PM, Gerben Wierda wrote: > Now, that says that syslog messages also end up in Unified Logging. What it > doesn’t say how for instance old style messages for facility mail with level > notice end up there. Or with facility daemon with level info. So, how to get > these out is still a riddle. They show up in unified logging. I found reading through the various manpages to be helpful - and there's an old WWDC video that you might find interesting: https://developer.apple.com/videos/play/wwdc2016/721/ > Why did Apple leave all the ASL stuff in place if it isn’t functional > anymore? It’s still there in Mojave. Why did they not offer a decent > compatibility? Afraid people would not move to OS-specific log commands? Sigh. Stuff compiled against previous versions of Mac OS X continues to work using the 'old' stuff (ie, if you built your own postfix and then upgraded your OS - it would still log the way it had done previously). I had a bunch of syslog.conf stuff that I moved to asl.conf that I now just don't have (or have half-replaced with use of the 'log' command). I find using 'log' to find logs much worse than using text-processing tools on text files - but we have to work with what we get from Apple. -- Daniel J. Luke
Re: Logging to syslog (by unbound, nsd, etc.) disappearing in a black hole
High Sierra switched the way syslog works on Mac OS (see https://developer.apple.com/documentation/os/logging). This replaced the ASL (and syslog) stuff. you can use the 'log' command line utility to view the logs. [I am not a fan of the way this stuff works now] > On Aug 15, 2019, at 3:46 AM, Gerben Wierda wrote: > > I’m running unbound. If I use file logging, it neatly ends up in the file I > want. If I set syslog in the conf file (this is standard in macports unbound > by the way) I get nothing. Logging disappears into a black hole, probably the > same black hole where mail logging from postfix disappears in on High Sierra > Server. > >use-syslog: > Sets unbound to send log messages to the syslogd, using sys- > log(3). The log facility LOG_DAEMON is used, with identity > "unbound". The logfile setting is overridden when use-syslog is > turned on. The default is to log to syslog. > > How do I make sure that I get to see the syslog messages. Probably by > adapting /etc/asl.conf and /etc/syslog.conf? Or is it a matter of ASL hiding > these kinds of messages from ordinary users? Is there a way to tell > asl/syslog to put the logging output of unbound into a (log rotated) file in > e.g. /var/log? > > PS. Apple is apparently playing around with unbound too: > > luna:~ gerben$ ls -l /usr/share/man/man8/unbound.8 > -rw-r--r-- 1 root wheel 2342 Aug 23 2018 /usr/share/man/man8/unbound.8 -- Daniel J. Luke
Re: Is there yet a clean way to upgrade to OpenSSL 1.1.1?
On Apr 18, 2019, at 5:05 PM, Bill Cole wrote: > Is there some approach that I'm not seeing to build against the new version > while leaving services that use the old version (and spawn worker children > while running) up and functional? I think your best bet is to wait for that PR to be merged, and then wait a little longer for binaries to be built for all of the other services that you have running - then your potential downtime for each service should be pretty short. You could, of course, replicate what the build infrastructure does if you don't want to be patient (but it would probably be a better use of your time to help out with testing the PR and getting everything ready for it to just be merged). -- Daniel J. Luke
Re: macpro burning through hard drives -- ? video card pulling too much power?
> I'm still not comfortable with SSDs that cannot tell you their health status > until they finally run out of spare blocks... Most SSDs have a smart attribute that lets you know how much wear is left on them (I have a Samsung SSD with attribute 177 and a Micron with attribute 202 which run from 100 down to 0 when the drive is 'used up') I haven't had any personal drives around long enough to tell if they're likely to die before then or not (I have backups on spinning rust). With my usage patterns, I'll almost certainly end up wanting to replace these drives before they get down to 50% anyway... -- Daniel J. Luke
Re: Experiences with union mounts in MacOS?
On Dec 16, 2018, at 11:03 AM, Ces VLC wrote: > But I'm a bit afraid because it seems to be a little used feature in the Mac, > so, if I'll be the only one in the planet using it, I guess it can be like > sort of a minefield walk, likely to use little-tested stuff. it would be interesting to see how well it worked (or didn't work), but I wouldn't want to rely on it for anything important. > I searched for it, and the only problems I saw reported is that Finder > doesn't seem to honor union mounts, but that wouldn't be a problem for me, as > I won't be using Finder for browsing the mount directory. If it works fine at > the Terminal, then it's fine for me. > > Do you have any experience using union mounts on MacOS? Did it work fine for > you? Did you find any problem/issues? I have a vague recollection of having problems with it back when I tried to use it for something that sounds similar (I wanted to use it to isolate changes made by a build or packaging system from the underlying OS). I don't recall why I ended up stopping that experiment, though. Since you're already using disk images, though - maybe you can use a shadowfile to get one layer of image combining? -- Daniel J. Luke
Re: 10.14 Mojave
On Oct 1, 2018, at 6:25 PM, Michael Newman via macports-users wrote: >> MacPorts, for the most part, works fine on macOS10.14 now. > > Does that mean that I can install Mojave and that installed ports will > continue to run without my having to install a newer MacPorts from source and > perform a migration? Apple does a really good job with ABI compatibility between releases, so this is usually the case for any OS upgrade - however, you don't actually want to do that, and MacPorts is going to want to rebuild all of your installed ports after you upgrade the OS. You're going to want to follow the migration instructions - https://trac.macports.org/wiki/Migration If you want to avoid building everything from source, you'll need to wait a bit (I don't think there's a Mojave build system set up yet, and even after it's set up it will probably take about a week for it to build all the packages it can build). -- Daniel J. Luke
Re: ClamAV: freshclam vs. sudo freshclam
For the list archives - Michael and I did some investigation off-list and it turned out to be Little Snitch blocking the freshclam invocation that wasn't working. > On Sep 5, 2018, at 10:03 AM, Daniel J. Luke wrote: > Were you able to get this working? > > If not, can you post the complete output from both the successful and > unsuccessful runs? > >> On Aug 20, 2018, at 7:51 PM, Michael Newman via macports-users >> wrote: >> If I run freshclam as a non-privileged user, it runs fine with no warnings >> or error messages. Here’s the last line of the response: -- Daniel J. Luke
Re: ClamAV: freshclam vs. sudo freshclam
Were you able to get this working? If not, can you post the complete output from both the successful and unsuccessful runs? > On Aug 20, 2018, at 7:51 PM, Michael Newman via macports-users > wrote: > > If I run freshclam as a non-privileged user, it runs fine with no warnings or > error messages. Here’s the last line of the response: > > Database updated (6622193 signatures) from db.TH.clamav.net (IP: > 104.16.188.138) > > But, if I run sudo freshclam it fails with numerous errors, some of which are > shown below. > > What do I need to do to fix this? > > WARNING: Can't query current.cvd.clamav.net > WARNING: Invalid DNS reply. Falling back to HTTP mode. > If-Modified-Since: Wed, 07 Jun 2017 21:38:10 GMT > Reading CVD header (main.cvd): nonblock_connect: connect(): fd=6 errno=64: > Host is down > Can't connect to port 80 of host db.TH.clamav.net (IP: 104.16.186.138) > nonblock_connect: connect(): fd=6 errno=64: Host is down > Can't connect to port 80 of host db.TH.clamav.net (IP: 104.16.188.138) > Trying host db.TH.clamav.net (104.16.187.138)... > nonblock_connect: connect(): fd=6 errno=64: Host is down > Can't connect to port 80 of host db.TH.clamav.net (IP: 104.16.187.138) > Trying host db.TH.clamav.net (104.16.189.138)... > nonblock_connect: connect(): fd=6 errno=64: Host is down > > WARNING: Can't read main.cvd header from database.clamav.net (IP: ) > Giving up on database.clamav.net... > Update failed. Your network may be down or none of the mirrors listed in > /opt/local/etc/freshclam.conf is working. Check > https://www.clamav.net/documents/official-mirror-faq for possible reasons. -- Daniel J. Luke
Re: nmap
On Sep 4, 2018, at 9:46 PM, James Linder wrote: >> On 5 Sep 2018, at 4:45 am, Daniel J. Luke wrote: >> On Sep 4, 2018, at 4:39 PM, Ryan Schmidt wrote: >>> It looks like he's showing us that nmap on his Linux machine found 11 hosts >>> while on his Mac it only found 6 hosts. >> >> maybe? and there a lots of reasons why that might be the case. > > Just to be more exact the linux machine is a vm on my mac with a bridged > network. > Daniel what can the ‘lots of reasons’ be? I can think of many, but it's probably not going to be helpful for you to enumerate the possible issues as the start of determining what's happening. I would probably start with seeing if I can ping all the hosts I expect to be able to ping from both the linux VM and from the Mac. -- Daniel J. Luke
Re: nmap
On Sep 4, 2018, at 4:39 PM, Ryan Schmidt wrote: > It looks like he's showing us that nmap on his Linux machine found 11 hosts > while on his Mac it only found 6 hosts. maybe? and there a lots of reasons why that might be the case. -- Daniel J. Luke
Re: nmap
On Sep 2, 2018, at 11:25 PM, James Linder wrote: > It seems the port of nmap is quite different to linux nmap. You haven't provided information to substantiate that assertion (but linux and mac os x /are/ different, so you might just be seeing those differences?) > What is happening one difference in what you pasted is that your linux machine has nmap 7.60 and your mac has nmap 7.7.0 -- Daniel J. Luke
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On Mar 21, 2018, at 2:23 PM, miniupnp <miniu...@free.fr> wrote: > It's quite fun to read exhortations to use upgrade to a more recent > system. I'm trying to imagine which hacker could spend time to exploit > Mac PPC machines to include them in a bitcoin mining botnet ;) or DDOS or SPAM or other abusive behavior that makes it harder for others to utilize a shared resource. but hey - at least you're having fun... [It's possible to safely use old systems, but it's not trivial. The easiest way to keep that old hardware useful is to run an OS that is still being supported - it's unfortunate that Apple doesn't keep releasing security patches for older systems, but there's nothing that we can do about that]. -- Daniel J. Luke
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On Mar 20, 2018, at 4:43 PM, Andreas Falkenhahn <andr...@falkenhahn.com> wrote: > IMHO there really should be prebuilt binaries for 10.4. It's a waste of > energy and resources to have everybody build this on his own... IMHO we shouldn't do anything to support Mac OS versions that aren't getting security patches from Apple anymore (since it's a dis-service to the rest of the people who use the internet when we make it easier for people to keep unpatched machines connected to that shared resource). if you really want it, it's possible for anyone to run a 10.4 build machine and share archives: https://trac.macports.org/wiki/howto/ShareArchives2 -- Daniel J. Luke
Re: Did anyone else's Perl 5.26 suddenly break?
In Dave's case, he's running a perl script and not building with a compiler -
so it's not CPPFLAGS but rather @INC changes with perl 5.26 that he's seeing.
As always, changes are described in perldelta:
http://search.cpan.org/dist/perl-5.26.0/pod/perldelta.pod#Removal_of_the_current_directory_(".")_from_@INC
> On Mar 6, 2018, at 4:00 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
>
>
> On Mar 5, 2018, at 22:09, Ryan Schmidt wrote:
>
>> On Mar 5, 2018, at 20:06, Dave Horsfall wrote:
>>
>>> A script that I wrote and has worked fine for ages is now breaking with:
>>>
>>> Can't locate Scanner.pm in @INC (you may need to install the Scanner
>>> module) (@INC contains:
>>> /opt/local/lib/perl5/site_perl/5.26/darwin-thread-multi-2level
>>> /opt/local/lib/perl5/site_perl/5.26
>>> /opt/local/lib/perl5/vendor_perl/5.26/darwin-thread-multi-2level
>>> /opt/local/lib/perl5/vendor_perl/5.26
>>> /opt/local/lib/perl5/5.26/darwin-thread-multi-2level
>>> /opt/local/lib/perl5/5.26) at ./uniscan.pl line 40.
>>> BEGIN failed--compilation aborted at ./uniscan.pl line 40.
>>>
>>> That "Scanner.pm" module is one I wrote myself, and it's definitely there.
>>>
>>> No, I haven't changed anything, and it works just fine on my FreeBSD (5.24)
>>> and Penguin (5.20) boxes. Older Mac versions of Perl also work (5.16,
>>> 5.22, 5.24).
>>>
>>> Rebooted (ugh!) to eliminate a corrupted image in swap: nope.
>>>
>>> Uninstalled and reinstalled in case the disk binary was corrupt: nope.
>>>
>>> Don't tell me that Perl 5.26 comes with a built-in time-bomb...
>>
>> Add -I to CPPFLAGS. Perl < 5.26 did so automatically, but 5.26 no longer
>> does.
>
> I meant: -I.
>
>
>> See for example
>> https://github.com/macports/macports-ports/commit/454eb2b0608266ab7bdf51a82d690be0f97610fe
--
Daniel J. Luke
Re: running macports along with homebrew
On Feb 14, 2018, at 5:33 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> wrote: > homebrew is easier to use, and works for 99% of people without any trouble. > > MacPorts is better in most ways, but a bit harder to use, and has more of a > learning curve to it. I think we should look at ways in which MacPorts is harder to use and see if we can address those. Homebrew has some 'hype' advantages (by using a more popular scripting language and making good use of github early on) - but also has repeated a lot of mistakes that MacPorts made early on (and seems to have eventually made many of the same decisions on how to avoid those problems - but I haven't looked recently at it since MacPorts does what I want really well). -- Daniel J. Luke
Re: running macports along with homebrew
On Feb 14, 2018, at 2:46 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> wrote: > On 2018-02-14, at 5:56 AM, Ryan Schmidt wrote: >> We will definitely never offer a user-facing feature for building the HEAD >> version of a port's code. > > I completely recognize why you stick with this, I totally get it, but this > caution is costing MacPorts both users and mindshare to do so... some people > want this, and so will go elsewhere to get it. > > In a recent poll > <https://www.slant.co/versus/1588/1674/~macports_vs_homebrew>, homebrew was > recommended 375 to 25 over MacPorts. > > Most developers who offer their software for download and building manually > recommend homebrew for supporting software. Almost nobody recommends MacPorts. sure, it's not clear that that's because MacPorts doesn't provide un-repeatable HEAD builds. > Reasons for this are likely to be: > > 1. a one-line copy-paste install script that can be embedded into any webpage. > > 2. symlinks into /usr/local therefore: >a) no adjustments needed to path >b) no need for sudo >c) third-party apps, libraries, and xcode projects can be downloaded and > built or run, and the system looks there by default, so need no modification > to build or run. > > 3. you can easily build the +HEAD version of a git project to try out newest > changes as a beta tester > > IMHO, the two biggest reasons homebrew is heavily recommended are #1 and #2c. > I think it's just good that we all know this. > > Question: > > Is there anything that would stop someone from installing macports into > /usr/local , yes, the configure script purposely errors out if you try to do this (I ran MacPorts this way for a /long/ time - there's no real benefit from doing so). > should they desire to do so? That would fix up all the issues with sudo, > path, and 2c. MacPorts already works with non-sudo if you want (we could probably make it easier). -- Daniel J. Luke
Re: lib dependency confusion
On Jan 12, 2018, at 5:22 PM, Bill Cole <macportsusers-20171...@billmail.scconsult.com> wrote: > All very well and good for a machine running an OS version that got the > ShellShock update from Apple. people probably shouldn't be running an OS version that hasn't been patched for a 4 year old vulnerability. > One of the use cases for MacPorts is to keep older Macs that are physically > capable of doing significant work (e.g. as servers) updated in regards to the > open source parts of MacOS. I don't believe MacPorts should be in the business of helping people keep vulnerable (unsupported by upstream security patches) systems connected to the shared public resource that is the internet. I agree that the hardware is still useful and would suggest that there are alternative operating systems that are maintained and receive security patches that they could run instead. -- Daniel J. Luke
Re: lib dependency confusion
On Jan 12, 2018, at 3:27 PM, Dave Horsfall <d...@horsfall.org> wrote: > Whether Apple wants to admit that its machines can crash and thereby cream > the filesystem is another question... presumably that's what macOS Recovery is for: https://support.apple.com/en-us/HT201314 -- Daniel J. Luke
Re: What's the push to require the latest Perl?
On Jan 11, 2018, at 3:33 PM, Dave Horsfall <d...@horsfall.org> wrote: > You might want to note that FreeBSD ports uses a ">=" test on versions e.g. > Perl 5.26 will satisfy the 5.24 requirement (unless, of course, there was the > aforesaid technical reason why it cannot). MacPorts doesn't support version comparisons in dependency specifications (this is a really old issue that's been discussed a lot over the years). > And if it comes down to a simple manpower issue, then let the record show > that I am willing to help if it will avoid people (like me) having to > have multiple versions of Perl bloatware (which reason, by the way, is why > I'm starting to move to Ruby instead; Python is for the birds). I look forward to seeing your contributions! Maybe you will come up with a solution that no one else has thought of yet. :) -- Daniel J. Luke
Re: port:openssl dependency
On Jan 10, 2018, at 2:49 PM, Jan Stary <h...@stare.cz> wrote: > these ports specify a hard dependency on openssl with "port:openssl". is libressl now ABI compatible with openssl? IIRC some ports moved from path back to port style dependencies on openssl since libressl was only 'source' compatible and so if you have a path-style dependency and users get things from the buildbot (that were built against openssl) they get non-working ports -- Daniel J. Luke
Re: What's the push to require the latest Perl?
On Jan 9, 2018, at 12:36 PM, Bill Cole <macportsusers-20171...@billmail.scconsult.com> wrote: >> On Jan 8, 2018, at 9:46 PM, Bill Cole >> <macportsusers-20171...@billmail.scconsult.com> wrote: >>> An issue with that is the fact that some amount of perl5 code in the wild >>> (often including widely-used non-core modules) is broken with each major >>> version. This is why upstream maintains 2 major versions at a time, >>> releasing a new version every Spring. So if MacPorts supports just one >>> version, it would need to be the older supported version for some months >>> after the annual release. >> >> We don't bend over backwards for compatibility with other ports, I don't see >> why we should treat perl specially in this case. > > Seriously? yes. > There are multiple obsolete versions of Python and Ruby actively maintained > in MacPorts many years after upstream EOL. PHP is a weirder case, with php4 > still there plus php5 which is "replaced by" php53 (obsolete) and the main > php port having sub-ports in all 4 maintained upstream branches as well as 4 > others that are long dead. Then there are the C/C++ compilers and the > databases... the number of these cases is outnumbered by counter-examples. I believe in almost all of the above cases it was a mistake to try to support multiple versions anyway (it's the 'easy' answer for 'hard' upgrades but is really just punting the upgrade problem to some point in the future). Python is 'special' since python3 isn't really compatible with python2 (so it would be wise to have a perl5 and a perl6 if perl6 ever becomes something people use). > I'm not arguing for supporting every upstream EOL version of everything, or > even ANY upstream EOL version of ANYTHING, but it's hardly "special" to > support the 2 upstream-maintained versions of a language. There's a lot of additional complexity in supporting multiple perls (along with supporting multiple versions of p5 ports that go with them). The project in general suffers from more things that would be good to do than people who are willing to do it. perl's backwards compatibility is good, so in my opinion, there's not a compelling use-case for supporting multiple versions of perl5. Maybe that means we wait a little while after an upstream perl5 release so that upstream p5 ports that are actively maintained get fixed. Anyway, I've argued this before and no one seems to like it - so we keep having to do the same work whenever there's a perl5 upstream release. -- Daniel J. Luke
Re: What's the push to require the latest Perl?
On Jan 8, 2018, at 9:46 PM, Bill Cole <macportsusers-20171...@billmail.scconsult.com> wrote: > An issue with that is the fact that some amount of perl5 code in the wild > (often including widely-used non-core modules) is broken with each major > version. This is why upstream maintains 2 major versions at a time, releasing > a new version every Spring. So if MacPorts supports just one version, it > would need to be the older supported version for some months after the annual > release. We don't bend over backwards for compatibility with other ports, I don't see why we should treat perl specially in this case. If an end-user needs to keep an older perl and associated modules around, they can either choose to not upgrade or handle it outside of macports. -- Daniel J. Luke
Re: What's the push to require the latest Perl?
On Jan 8, 2018, at 1:36 PM, Bill Cole
<macportsusers-20171...@billmail.scconsult.com> wrote:
> I think a better approach would be to either require the p5-foo port OR
> (better) require path:${perl5.lib}/Foo.pm:p5.${perl5.major}-foo or (best)
> create a new syntax for dependencies that check for functionality, i.e. use
> the return value of 'perl -e "use Foo 6.66;"' to decide whether to install
> p5.${perl5.major}-foo @6.66 (or greater)
or most simply:
Provide one version of perl5 (whatever the current released version of perl
is). Provide p5-foo ports that build with whatever the current perl5 is. There
isn't a good reason to try to support multiple versions of perl5, if we didn't
try to do so we could jettison all of this complexity.
--
Daniel J. Luke
Re: switching between x11 and quartz
On Oct 30, 2017, at 12:18 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> wrote: > As you probably know, homebrew runs it's entire operation that way, > symlinking into /usr/local. homebrew has over its history followed a similar path that MacPorts has (re-learning many of the same lessons). I don't know if they've fixed the issues we saw, if they've decided they aren't important, or if they will eventually give up this strategy (as MacPorts did). -- Daniel J. Luke
Re: switching between x11 and quartz
On Oct 27, 2017, at 8:33 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > I don't know if anything will break if you use symlinks; I would expect most > ports would work but some might not. Long ago, macports used to use symlinks in some cases to activate ports. It did mostly work, but the cases where it didn't were frustrating. I'm sure there's data in the list archives about it if one is really curious. -- Daniel J. Luke
Re: upgrade apache2 2.4.28_0 < 2.4.28_2 destroyed .conf files!
On Oct 19, 2017, at 11:29 AM, Marius Schamschula <li...@schamschula.com> wrote: > However, I don’t see how this could have happened, as apache2 @2.4.28_2 was > modified to not do this very thing, i.e. it moves the .conf files to > .conf.orig in the post-destroot phase, before activation. 2.4.28.0_0 'owned' .conf files - so they probably would have been removed when uninstalling for the upgrade. As of 2.4.28.0_2 the behavior is fixed (you can verify with 'port contents apache2) and so shouldn't cause future problems. -- Daniel J. Luke
Re: Uninstall a port and ONLY THAT PORT's dependencies?
On Oct 2, 2017, at 6:47 PM, Dave Horsfall <d...@horsfall.org> wrote: > In other words, I appear to have stumbled across an obscure MacPorts bug, yet > not having enough information on hand to be able to report it properly; I > merely pointed out that your claim is demonstrably incorrect. I suspect that in your case you simply have ports installed from before the 'requested' flag was tracked by MacPorts (that's certainly behavior I've seen and is the main reason why I haven't personally used the 'requested' flag for anything). -- Daniel J. Luke
Re: running macports along with homebrew
On Aug 31, 2017, at 3:34 PM, Craig Treleaven <ctrelea...@macports.org> wrote: > AIUI, casks are supposed to help in two ways: binary (only) packages and > pre-compiled binaries. > > MacPorts solved the second part several years ago. As an aside, I think a > lot of people using Homebrew never got this message. Indeed, a quick look at pacakges.macports.org indicates there are 22,957 binary archives available. > Maybe I’m missing something important. I get that feeling a lot when talking to people who really like homebrew. -- Daniel J. Luke
Re: libxml2 2.9.4 config error #54070 wontfix
On May 31, 2017, at 11:12 AM, db <iams...@gmail.com> wrote: > On 31 May 2017, at 15:16, Daniel J. Luke <dl...@geeklair.net> wrote: >> yes, but base doesn't currently know that it should do that (this thread >> contains some suggestions about how that might be possible). > > I meant doing this from within base for the handful of utilities they are — > no prio ports, no soft deps. Yes, Mojca mentioned this idea in: https://lists.macports.org/pipermail/macports-users/2017-May/043384.html -- Daniel J. Luke
Re: libxml2 2.9.4 config error #54070 wontfix
On May 30, 2017, at 4:24 PM, Ryan Schmidt <ryandes...@macports.org> wrote: >> Another semi-weird solution would be to somehow declare a list of >> "high priority" ports that always get updated first even if no other >> port depends on them (either in the core or as a special keyword in >> the Portfile). > > My initial impression of this idea is that I like it, for gawk, grep, gsed, > and any others that are automatically searched for by default configure > scripts. But remember that those ports have dependencies. Not many, but each > of those dependencies would have to be handled by my previous suggestion, > modifying each to ensure only the system version of those utilities is used. For this particular class of problems (autoconf picking up gawk/gsed, etc.) base could populate the environment with the system awk/sed etc. (ie base could do what the APR port does with configure.env). Or, base could auto-add these soft dependencies for anything that does the 'normal 'configure' phase. -- Daniel J. Luke
Re: macPorts selfupdate returned error 1
Glad it's working for you - this was actually this bug: https://trac.macports.org/ticket/53414 (you had a very old config option in your macports.conf file that caused the build to fail) > On May 19, 2017, at 8:56 AM, Howard Baumer <howba...@me.com> wrote: > Thanks Mojca, uninstall of ports, clearing out the old macPorts and > installing for El Capitain did the trick -- Daniel J. Luke
Re: Prevent MacPorts editing .bash_profile over and over again...
On Mar 21, 2017, at 9:30 AM, Jan Stary <h...@stare.cz> wrote: > I appreciate you concern about being spammed with trivia. > But it's one line in ~/.profile, which is equally trivial. While I agree with you in principle (see list archives where I disagreed with adding this to the installer way back when it was first introduced) - Ryan is right that we used to get lots of support requests where people apparently weren't capable of reading the instructions and updating their $PATH themselves. Our actual experience around this issue tells us that it's worse to not try to set $PATH in the installer. > I find mangling the user's shell configuration worse: > someone who uses macports to install software > is capable of editing one line in their config if told so. users who are smart enough to edit their configs are also smart enough to install from source (where you don't have this issue at all). -- Daniel J. Luke
Re: Is Macports down?
On Mar 7, 2017, at 10:55 AM, Dave Horsfall <d...@horsfall.org> wrote: > On Tue, 7 Mar 2017, Dave Horsfall wrote: > A posting on an unrelated subject reminded me about something: I recently > upgraded my broadband service from ADSL (copper) to fibre, and a new > router was supplied. I've since discovered that the router (a Sagemcomm > F@st 5355), get this, *does not pass outbound UDP packets*! (And I cannot > configure its firewall to do so.) So things like NTP and TRACEROUTE etc > are stuffed... DNS uses udp (and some tcp). I'd be really surprised if it blocked /all/ udp packets (and if so, I would get my provider to replace it or let me replace it with something that didn't suck). > So, my question is: is UDP used anywhere in the update process? The rsync itself uses tcp -- Daniel J. Luke
Re: Trac login
On Mar 6, 2017, at 1:50 PM, Geoff Down <geoffd...@fastmail.net> wrote: > If anyone involved with the ntp port is listening, um, you mean me? (hint, maintainers are listed when you do `port info portname`) > ntp-4.2.8p9.tar.gz > has disappeared from the macports site and the mirrors. you mean the distfile (or binary) isn't being mirrored? That'd be an MacPorts infrastructure issue (or a license issue), so I probably wouldn't be able to help fix it. The port should still work, though. -- Daniel J. Luke
Re: Logging in Sierra
On Feb 7, 2017, at 12:28 PM, William H. Magill <mag...@mac.com> wrote: > Have various applications, such as Apache, Postfix and Mailman, been > modified/updated to log appropriately under the new OSX logging scheme in > Sierra? They don't need to be updated. > Apache apparently logs independently of syslog - however bothy Postfix and > Mailman (according to their respective websites) use syslog - which > apparently no longer works in Sierra. Apple changed the way the syslog api works (if you build against an older sdk you still get the old behavior). -- Daniel J. Luke
Re: Prevent MacPorts editing .bash_profile over and over again...
I think only the pkg installers do that - and they're supposed to not edit the $PATH if $prefix is already in there. (ie if you upgrade using `port selfupdate` I don't think you have that problem). Or am I mistaken? > On Jan 28, 2017, at 4:56 PM, Barry <ba...@barrys-emacs.org> wrote: >> On 28 Jan 2017, at 16:37, Christopher Jones <jon...@hep.phy.cam.ac.uk> wrote: >> Hi, >> >> It would be better yet if whatever it is that does this first checks to see >> in the path it is about to add is already in the users PATH, and does not >> add it again if already there… > > That would be an improvement. > > I would also like a way to say never edit my .bash_profile. > Maybe a comment line specially formated. > > # MacPorts: no-edit-path > > Barry > >> Chris >> >>> On 28 Jan 2017, at 4:31 pm, Barry Scott <ba...@barrys-emacs.org> wrote: >>> >>> I want to be able to stop MacPorts Installation from editing my >>> .bash_profile. >>> As it happens I already set all the env var that are needed my self. >>> >>> Is there a “do-not-edit-bash-profile” settings somewhere? >>> >>> So far I have 3 sets of the settings in the same file. >>> >>> Barry -- Daniel J. Luke
Re: MacPorts 2.4.0 has been released
On Jan 27, 2017, at 4:05 PM, Adam Dershowitz <de...@alum.mit.edu> wrote: > I have another question about another new feature. > Is there a way to see what port reclaim will do? It says that it doesn’t > accept any switches on the Using Macports page. And, it could delete a lot > of stuff. Something similar to “-y” would be a nice way to see what it would > do, if allowed. Is there any way to do that? It will prompt you with the option to list the things it found (and delete them or not). I just ran it on a couple of machines here and it works nicely. -- Daniel J. Luke
Re: Migration issue
> So, this suggests that there might be some combination of the long list of > ports below that I could uninstall +universal, then install default, and that > might allow wine to build? well, I was suggesting that you can even 'uninstall' any 'build' dependencies after they've been used to build something (since they're not needed at runtime). you probably shouldn't care too much about what is or isn't installed +universal if your ports are working, though. > But, no easy way to figure out which combination? Macports might or might > not want to update any given port to +universal? > > At the moment my libunistring is not +universal. Although, perhaps the > reasons that macports wants to rebuild textlive that way, is that it can > rebuild that as well. to get your stuff working, you could probably uninstall libunistring, install textlive (non-universal) and then install libunistring +universal while telling MacPorts not to look at dependencies (-n) [although I haven't tested that, so it might not work since IIRC the build_arch +universal stuff is 'special'] -- Daniel J. Luke
Re: Migration issue
python3_select xorg-libXrandr xorg-randrproto xorg-libXcursor xorg-libXinerama xorg-xineramaproto xorg-libXcomposite xorg-compositeproto at-spi2-atk dbus at-spi2-core gtk-doc libxslt openjade xmlcatmgr opensp fop docbook-xml docbook-xml-4.1.2 docbook-xml-4.2 docbook-xml-4.3 docbook-xml-4.4 docbook-xml-4.5 docbook-xml-5.0 docbook-xsl itstool gawk readline source-highlight boost icu ctags xorg-libXtst xorg-recordproto hicolor-icon-theme gstreamer1-gst-plugins-base libopus orc coreutils gmp xorg-libXv xorg-videoproto libogg libvorbis libtheora lcms2 libpcap gnutls libtasn1 libunistring texlive-basic texlive-common texlive-bin libzzip xmlto getopt findutils libpaper poppler openjpeg jbigkit poppler-data harfbuzz-icu mpfr potrace xorg-libXp xorg-printproto xpm xorg-libXaw groff ghostscript jbig2dec psutils netpbm subversion apr apr-util db46 serf1 scons cyrus-sasl2 kerberos5 libcomerr libmagic libnetpbm p11-kit desktop-file-utils popt nettle libGLU -- Daniel J. Luke
Re: Macports needs a little marketing ....
On Nov 16, 2016, at 10:16 AM, Mojca Miklavec <mo...@macports.org> wrote: > The only thing that could be done would be a slight delay between > master and "stable". For example everything that's in master would go > to "quasi-stable" after a week unless some problems are discovered > (and then the port would be held back). But this requires extra > manpower again. Something we lack already. I think it would be nicer to just be able to have ports tagged with some metadata (passes lint, buildbot was able to process, installed by n # of users who have agreed to send stats back to the project, etc.) End users could use the metadata to make the kinds of decisions one might make for 'stable' vs. 'unstable' stuff elsewhere. -- Daniel J. Luke
Re: selfupdate fails with '"/tarballs/ports.tar" (in release) failed: No such file or directory'
On Nov 14, 2016, at 10:38 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > Because of the slow network connection, if someone commits updates to a large > port, we have already at times observed a single sync taking over 24 hours. Which network connection is slow? (from you to rsync server)? -- Daniel J. Luke
