Re: My Monday morning moans - malformed macho

Or to put it another way, relax: this particular malformed_macho has nothing to do with what the #MeToo folks complain about. :-) > On Mar 10, 2019, at 19:11, Richard L. Hamilton wrote: > > While someone who can speak authoritatively needs to confirm this, the name > certainly sug

Re: My Monday morning moans - malformed macho

While someone who can speak authoritatively needs to confirm this, the name certainly suggests a Mach-O (Mac's object file format) executable that's purposely malformed as test data for routines that manipulate object files. As such, it probably _should_ be corrupt, and is probably not cause

Re: [macports-ports] branch master updated: nrpe, nsca: remove outdated ports

How about maildrop? Nothing I know of (except procmail) will use existing .procmailrc files, but e.g. http://www.wonkity.com/~wblock/docs/html/maildrop.html shows some examples of migrating (e.g. sendmail configuration, some .procmailrc

Re: Anyone running X11 apps on Mojave? [Solved]

Instead of that line in .bash_profile, as long as all the systems you use your login (if you're using OpenDirectory) on have /opt/local/bin/bash installed, the Unix way would be to add /opt/local/bin/bash to the list of shells in /etc/shells (if that file doesn't exist, it's as if it existed

Re: problem with reactivating ports

> On Jan 14, 2019, at 08:34, Bill Cole > wrote: > > On 14 Jan 2019, at 2:46, Werner LEMBERG wrote: > >> Hello Ryan! >> >> >>> Do you need those old inactive versions? If not, you could >>> uninstall the inactive ports before beginning the exercise. >> >> Is there a safe command to

Re: uninstall residues (MacPorts others) in Launcher

> On Dec 21, 2018, at 10:01, Christoph Kukulies wrote: > > The problems with Gimp seemed to have some resemblance with this. Although I > must say that the „official“ download for macOS on gimp.org > also comes up in that kind of dark mode. Seems to be en > vogue these

Re: Texting

I don't know of an existing port, but here's something that could do the job. The paid service is more reliable, but the free one running on one's own system might be sufficient. I gather it knows many of the email gateways and has some way of determining for most numbers which to use. It

Re: Experiences with union mounts in MacOS?

I just tried (Mojave) a couple of times. Once, a dmg attached but manually mounted over a non-empty directory; didn't see the contents below, although I suppose I might have messed up somehow. Another time, an NFS mount over the same non-empty directory, where I _did_ see both. The dmg had

Re: Anyone running X11 apps on Mojave?

One might suppose there are still people for which the standalone packaging of Xquartz might be preferable - people that for whatever reason, don't want to deal with the extra steps involved in installing MacPorts (including installing Xcode plus command line tools), let alone updating it, and

ports to replace removed Server components

Per Wikipedia, the mail/IMAP support formerly in Server consisted of: SMTP (Postfix) POP and IMAP (Dovecot) SSL/TLS encryption (OpenSSL) Mailing lists (Mailman) Webmail (RoundCube) Junk mail filtering (SpamAssassin) Virus detection (ClamAV) I see that MacPorts has most of those, but not RoundCube

Re: Updating ffmpeg ...

sh-3.2$ port installed ffmpeg The following ports are currently installed: ffmpeg @4.0.2_1+gpl2+x11 (active) sh-3.2$ type ffmpeg ffmpeg is /opt/local/bin/ffmpeg sh-3.2$ otool -L /opt/local/bin/ffmpeg | grep libx2 /opt/local/lib/libx264.152.dylib (compatibility version 0.0.0, current

Re: rsyncd with macports 2.5.4 on macOS 10.13.6

(when sufficient) directly rather than using the Portfile startupitem functionality? > On Oct 25, 2018, at 13:52, Ryan Schmidt wrote: > > > > On Oct 25, 2018, at 10:08, Kevin Layer wrote: > >> Richard L. Hamilton wrote: >> >>>> I've had issues

Re: rsyncd with macports 2.5.4 on macOS 10.13.6

-w /Library/LaunchDaemons/org.macports.rsyncd.plist sudo launchctl load -w /Library/LaunchDaemons/local.rsyncd.plist > On Oct 25, 2018, at 11:08, Kevin Layer wrote: > > Richard L. Hamilton wrote: > >>> I've had issues before with the whole daemondo wrapper bit. Some >>&

Re: rsyncd with macports 2.5.4 on macOS 10.13.6

I've had issues before with the whole daemondo wrapper bit. Some things may need it, given how launchd has different expectations from other system's approaches to starting daemons, and some daemons may not have a sufficiently compliant behavior without daemondo as an intermediary. But when

recent comment on #57234 - new build system documentation

The comment in question referenced: https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes/build_system_release_notes_for_xcode_10 I'd

Re: xephem seg faults on Mojave

one had to link libXt with -flat-namespace if libXm was going to work with it (I think that's how it went), if one didn't do that. > On Oct 11, 2018, at 06:00, Richard L. Hamilton wrote: > > The current version (3.7.7) is three years old, and apparently quite stable > (I've run it o

Re: xephem seg faults on Mojave

and OpenMotif libraries, which certainly simplifies distribution), and doesn't use MacPorts, so whatever linkage issue (probably, IMO!) this is, he wouldn't encounter anyway. > On Oct 11, 2018, at 05:24, Chris Jones wrote: > > > > On 11/10/18 10:07, Richard L. Hamilton wrote: >

Re: xephem seg faults on Mojave

It doesn't have to be a bug with xephem (the code) at all, but with the build procedure, which apparently can have a lot of breakage going to Xcode 10. > On Oct 11, 2018, at 04:30, Chris Jones wrote: > > > >> The same version of Xephem ran fine on 10.13 when using the Fink packaging >>

Re: Qt4/KDE4 software under 10.14

at native was slow, although kshisen is not demanding, and I may not have run it before on this relatively new hardware back on High Sierra, so I might not notice speed anyway. > On Oct 11, 2018, at 04:04, René J.V. Bertin wrote: > > On Thursday October 11 2018 01:37:51 Richar

Re: Qt4/KDE4 software under 10.14

libkdegames doesn't build yet, due to some changes in build procedures apparently; there is a ticket, and hopefully there will shortly be a proper fix. Having said that, with a jury-rigged way around that (not correct, but it works), all the KDE4 games would build. But they have display

Re: Qt4/KDE4 software under 10.14

I wonder if the flashing isn't a rendering issue similar to what MacVim is having, where the behavior of a legacy rendering technique changed? > On Oct 10, 2018, at 14:57, Michael Dickens wrote: > > The Qt4-provided native apps seem to work correctly with no display issues. > > I have "my

Re: xephem seg faults on Mojave

To me it sounds almost like back when xorg-libXt needed to be linked with a -flat-namespace option if one was going to use openmotif with it. But as I recall, the current version of open motif isn't supposed to need that anymore But it could still be a building or linking issue, something to

Re: MacVim, installed binary port, but still blinks

et. > > https://github.com/macvim-dev/macvim/issues/751 > <https://github.com/macvim-dev/macvim/issues/751> > > Ken > > On Oct 10, 2018, at 02:02, Richard L. Hamilton <mailto:rlha...@smart.net>> wrote: > >> It runs, but blinks. >> >>

MacVim, installed binary port, but still blinks

It runs, but blinks. There's a workaround: start MacVim, and uncheck Preferences -> Advanced -> Use Core Text renderer Then quit MacVim, and when you start it, it shouldn't blink anymore. I gather that a better fix is pending upstream.

KDE4 apps blink?

As a temporary measure, I downloaded a prebuilt MacVim.app from Macupdate. It works, but the window _blinks_. Same with the kshisen app that I got built once I followed a suggestion how to get libkdegames built. They're not even using the same copy of the Qt/KDE libraries, since the

mpv @0.28.2_1 builds on mojave but video is blank

The audio plays fine, and the window comes up the right size, but it's always black, with a variety of files (mp4, mkv, m4v, avi, swf, at least; what I had handy to try). It worked back on High Sierra (same version of mpv, I think). And I made sure I built ffmpeg with the same variants I'd

migration to mojave, my experience so far

FYI, here's my list so far of build failures I've encountered for mojave. All have tickets, either existing or that I filed. Four are already ok. mysql57 isn't on the list, but #57273 tells how to get it built (need ld64 +ld64_xcode, and probably not other versions of ld64). Of course, I

Re: port not installing

Something about your setup may be broken; it installed fine for me (yes, that's on Mojave): bigapple:~ root# port install nco ---> Computing dependencies for nco The following dependencies will be installed: antlr cunit netcdf udunits2 xercesc3 Continue? [Y/n]: y ---> Fetching archive for

soprano on Mojave not finding Java developer header files

This change to the Portfile got it to build for me; apparently those files are in a different location now, so the original pre-check failed (properly installed Xcode and command line tools will find it regardless of the pre-check, so this is all that needed to be changed). Since soprano is a

Re: dosbox update?

...@gmail.com>> wrote: >> >> I have the update done and I'm using it now. >> >> Just working out the final dets. >> >> Ken >> >> On 2018-10-03, at 4:23 PM, Richard L. Hamilton wrote: >> >>> On www.dosbox.com <ht

dosbox update?

On www.dosbox.com , I see Thursday, August 30th, 2018 - Qbix DOSBox 0.74-2 has been released! A maintenance release for DOSBox 0.74, which solves the following problems: Windows: Fix auto/max cycles algorithm on Windows 7, which helps with stuttering audio. Mac OS X:

xplanet (at least as of 1.3.1) does not need supported_archs 386 ppc for aqua variant

Since a 32-bit build of xplanet presumably wouldn't work on Mojave, which I'd like to move to, just for giggles I removed that line from the Portfile, uninstalled, and reinstalled. It successfully built a 64-bit executable, which works (at least in the trivial case of run the command with no

Re: User information about macOS Mojave

Clearly you can install 9.4.1 on Mojave...and it seems to work at least for trivial code, even compiling to 32 bit: sh-3.2$ uname -a Darwin bigapple-mojave.pri 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64 sh-3.2$ xcode-select

Re: User information about macOS Mojave

> On Sep 19, 2018, at 11:49, Julien Salort wrote: > > Le 19/09/2018 à 17:12, Ken Cunningham a écrit : > >> I haven't dived into Mojave yet, but if all the system libraries in >> /usr/lib and all the Frameworks are x86_64 only, then I don't see how that >> could work, even if you compiled

Re: no longer quite OT

As for password-less, you don't need MacPorts sshd for that. Some OS versions back, that just worked. Now you have to do a little bit to make it work (outgoing - it still works incoming, with the usual measures, give or take something odd in /etc/ssh/sshd_config). Here's some discussion

Re: SOS!

sudo tmutil listlocalsnapshots / would list the APFS snapshots created by Time Machine. (not sure it would list others, nor what distinguished those; naming convention, probably) There was another program in the beta, gone in the regular release of High Sierra, called apfs_snapshot; but one

version script

Here's something I put together that spits out most of the information about a system (other than e.g. the build log for a port that failed to install/update) that might be of interest when problems arise.  Sample output:sh-3.2$ versHardware Version: MacBook Pro (15-inch, 2017)Model Identifier:

build error on Snow Leopard trying to fetch a patch file for clang-6.0

---> Fetching distfiles for clang-6.0 ---> Attempting to fetch 2001-xray-Define-O_CLOEXEC-for-older-SDKs-that-don-t-have.patch from https://distfiles.macports.org/llvm ---> Attempting to fetch 2001-xray-Define-O_CLOEXEC-for-older-SDKs-that-don-t-have.patch from

Re: iTerm2 and High Sierra 10.13.6 incompatible...

> On Jul 18, 2018, at 20:42, Mark Anderson wrote: > > Yeah, open a ticket. I'll take a look. I think we stopped the autoupdate > dialog before, but it moved around on us. I need to bump to at least 3.1.7 > anyway. > > —Mark Ok, thanks. #56840 While

Re: iTerm2 and High Sierra 10.13.6 incompatible...

> On Jul 18, 2018, at 15:20, Ryan Schmidt wrote: > > > > On Jul 18, 2018, at 14:17, Richard L. Hamilton wrote: > >> But...as soon as I tried to run it, it popped up its own updater telling me >> that 3.1.7 was available. Now I know enough NOT to use a non-Mac

Re: iTerm2 and High Sierra 10.13.6 incompatible...

BTW, I just tried installing iTerm2 (on 10.13.6), no problem, installed the pre-built version 3.1.6. But...as soon as I tried to run it, it popped up its own updater telling me that 3.1.7 was available. Now I know enough NOT to use a non-MacPorts updater on something installed via MacPorts,

Re: iTerm2 and High Sierra 10.13.6 incompatible...

Not that it may make the difference, but have you tried port clean --all iTerm2 before trying to reinstall? That should at least get rid of all debris from any previous attempt, I'd hope. :-) > On Jul 18, 2018, at 14:48, Comer Duncan wrote: > > The thing is that I've now uninstalled

Re: inetutils permissions?

we're not already using tools that would conflict with as part of port processing. > On Jul 14, 2018, at 13:59, Bill Cole > wrote: > > On 14 Jul 2018, at 2:09 (-0400), Richard L. Hamilton wrote: > >> rlogin, rsh, and I think rcp need to be setuid root, because they have

inetutils permissions?

rlogin, rsh, and I think rcp need to be setuid root, because they have to use privileged ports. But they were installed without the setuid root permission set (they worked normally after setting it by hand). Is there any reason that isn't set as part of installation? Granted it's not without

Re: smartctl - Can't run select span range

S. > > -Ubence > > On Mon, Jun 25, 2018 at 7:16 AM Richard L. Hamilton <mailto:rlha...@smart.net>> wrote: > Looks to me like the code purposely and intentionally disallows that on a > Mac. No idea why - maybe the OS won't do it or doesn't like i

Re: smartctl - Can't run select span range

Looks to me like the code purposely and intentionally disallows that on a Mac. No idea why - maybe the OS won't do it or doesn't like it. In os_darwin.cpp: 483 case ATA_SMART_IMMEDIATE_OFFLINE: 484 select = in.in_regs.lba_low; 485 if (select != SHORT_SELF_TEST && select !=

Re: Preventing check of sharedlibs in rev-upgrade

> On Jun 20, 2018, at 07:34, Joshua Root wrote: > > Artur Szostak wrote: >> Is there any way of telling MacPorts to not consider one, more or all shared >> libraries when attempting its check for broken libraries in a Portfile? I >> have some Java software which is precompiled and also

Re: kdelibs4@4.14.3_10 build fails on High Sierra

gt; wrote: > > > On May 2, 2018, at 21:41, Richard L. Hamilton wrote: > >> Oddly enough, it builds fine on older e.g. El Capitan (I think even on Snow >> Leopard, but that box is slow, so I don't know yet). >> >> Will I have better luck using a different compiler, or d

kdelibs4@4.14.3_10 build fails on High Sierra

Oddly enough, it builds fine on older e.g. El Capitan (I think even on Snow Leopard, but that box is slow, so I don't know yet). Will I have better luck using a different compiler, or does it just hate me? :-) I have 4.14.3_8 installed now (don't recall whether it was pre-built, or whether I

upcoming removal of components from macOS Server: opportunity?

"In fall 2018, Apple will stop bundling open source services such as Calendar Server, Contacts Server, the Mail Server, DNS, DHCP, VPN Server, and Websites with macOS Server. Customers can get these same services directly from open-source providers. This way, macOS Server customers can install

Re: Rsync and --protect-decmpfs

AFAIK, that option is specific to HFS+ with compression, preserving an associated extended attribute; but it preserves it even if the receiving end doesn't know what to do with it properly (whatever that is); so I'd want the destination system to be as new or newer, to be reasonably sure it

pciutils?

The lspci command might be handy for those not wishing to parse native tools in hopes of finding similar info. The version at https://mj.ucw.cz/sw/pciutils/ built easily enough for me, although it does require boot-args debug=0x144 (as well as running it as

Re: scp ignores case in filenames?

> On Jan 19, 2018, at 09:53, db wrote: > > On 19 Jan 2018, at 15:23, Vincent Habchi wrote: >> I’ve been working for years on case-sensitive HFS+/APFS file systems (coming >> from BSD Unix) and never encountered any problem. Only PyCharm needs an >>

Re: scp ignores case in filenames?

> On Jan 19, 2018, at 05:23, Jan Stary wrote: > > This is of course not MP related; > please kindly point me to the appropriate Apple forum. > > Create a local file: > > user@local$ echo local > /tmp/file > > Prepare a file on a remote machine, > with the "same" name,

netpbm@10.81.01+universal+x11 build failed on Snow Leopard

Looks like at least the immediate problem (not to say there might not be others) is that strnlen() is missing on Snow Leopard. When this came up for something else before, some magic known as snowleopard_fixes took care of it, according to old email. I gather that supplies the functions

coreutils @8.29 +universal config failure on Snow Leopard

It did build without +universal (or more accurately, with -universal, just to be sure). Since port rev-upgrade passed after that, I didn't think that workaround was a big deal; I'm ok with it, assuming nothing else uses the one shared object (/opt/local/libexec/coreutils/libstdbuf.so) it seems

libcxxabi @3.9.1_2+universal failed to build on Snow Leopard

I don't think this relates to any of the existing tickets. Not sure how I'd even describe it, although it looks like maybe the wrong compiler is being used? version:1 :msg:clean ---> Computing dependencies for libcxxabi:info:clean .:debug:clean libcxxabi has no conflicts :debug:clean Searching

Re: telnet and ftp missing in High Sierra - ideas/suggestions?

> > You are looking for the inetutils port. Under High Sierra it installs the > missing server and client utilities. > >> On Nov 28, 2017, at 1:32 PM, Richard L. Hamilton <rlha...@smart.net >> <mailto:rlha...@smart.net>> wrote: >> >>

telnet and ftp missing in High Sierra - ideas/suggestions?

I can see ditching the telnet server, but the client remains useful for debugging various protocols, and in rare cases of accessing ancient systems (or emulations of them) which don't support ssh. Likewise, there remain times a command-line ftp client is useful. I see some of what look like

Re: xorg-libXt won't build because xsltproc processes never finish

> On Nov 19, 2017, at 17:55, Ryan Schmidt <ryandes...@macports.org> wrote: > > On Nov 19, 2017, at 14:26, Richard L. Hamilton wrote: >> > >> On Nov 19, 2017, at 14:35, Ryan Schmidt wrote: >> >>> On Nov 19, 2017, at 09:27, Richard L. Hamilton w

Re: xorg-libXt won't build because xsltproc processes never finish

> On Nov 19, 2017, at 14:35, Ryan Schmidt <ryandes...@macports.org> wrote: > > > On Nov 19, 2017, at 09:27, Richard L. Hamilton wrote: > >> Reinstalling after migrating to High Sierra, it had to be that something >> wouldn't rebuild, and this was it

xorg-libXt won't build because xsltproc processes never finish

Reinstalling after migrating to High Sierra, it had to be that something wouldn't rebuild, and this was it. xorg-libXt won't build because the xsltproc processes never finish. For giggles, I temporarily swapped the one already in /opt/local/bin with the somewhat older binary supplied by

Re: lame and libuv now using strnlen() which is missing on Snow Leopard and earlier

t; >> On Nov 8, 2017, at 1:26 AM, Richard L. Hamilton <rlha...@smart.net> wrote: >> >> Due to missing strnlen() which both lame and libuv now use, neither builds >> on Snow Leopard (or earlier, presumably). >> >> Looking for strnlen on my system ("locate

lame and libuv now using strnlen() which is missing on Snow Leopard and earlier

Due to missing strnlen() which both lame and libuv now use, neither builds on Snow Leopard (or earlier, presumably). Looking for strnlen on my system ("locate" command), I saw a number of other ports have patches for that issue, which is why I gather that these two are only now using that

Re: clang-3.9 wrappers now broken on Snow Leopard

> On Oct 2, 2017, at 19:35, Ryan Schmidt <ryandes...@macports.org> wrote: > > > On Oct 2, 2017, at 07:18, Richard L. Hamilton wrote: > >> The wrappers with the clang-3.9 port that look like >> >> #!/bin/bash >> >> if [ -x /usr/bin/xcrun ]

clang-3.9 wrappers now broken on Snow Leopard

The wrappers with the clang-3.9 port that look like #!/bin/bash if [ -x /usr/bin/xcrun ] ; then exec /usr/bin/xcrun /opt/local/libexec/llvm-3.9/bin/clang "${@}" else exec /opt/local/libexec/llvm-3.9/bin/clang "${@}" fi have a problem on Snow Leopard: myeye:tmp root# clang-mp-3.9

Re: xcode, clt or both

By "We are trying to move toward a future where MacPorts recommends installing only Xcode, and not the command line tools", does that mean that only Xcode will be required then, or that the command line tools should actually be avoided? Some people will wish to have both, for reasons having

On Snow Leopard, updating at-spi2-atk to @2.26.0_0+universal failed unless at-spi2-core updated first

Hardware Version: Mac mini (Mid 2007) Model Identifier: Macmini2,1 Mac OS X 10.6.8 10K549 (Snow Leopard) Xcode 3.2.6 DevToolsSupport-1806.0 MacPorts Version: 2.4.1 The error in the log file seems to say as much: :info:configure checking for atk >= 2.25.2... no :info:configure configure: error:

Re: smake@1.2.5 fails to build on Snow Leopard

; cdrtools @3.00_1 (active) platform='darwin 10' archs='x86_64' > date='2017-09-02T11:22:23-0700' > > > > Perhaps open a ticket so we can sort out what's going on over time. > > Ken > > > > > > On 2017-09-02, at 6:27 AM, Richard L. Hamilt

smake@1.2.5 fails to build on Snow Leopard

I suspect the absence of the latest smake may also cause the failure of the latest cdrtools to build (since building it uses smake, and IIRC they're both from the same author); but until I can get the latest smake built, I won't know for sure. :-) main.log-smake.txt.gz Description: GNU Zip

Re: running macports along with homebrew

> On Aug 29, 2017, at 18:54, db wrote: > > On 29 Aug 2017, at 23:24, Ryan Schmidt wrote: >> The best practice is not to do that. We don't support it. It can cause you >> problems that we don't want to spend time investigating, because they >>

Re: mcrypt failure?

> On Aug 28, 2017, at 13:05, Rainer Müller <rai...@macports.org> wrote: > > On 2017-08-24 22:50, Richard L. Hamilton wrote: >> Attempting >> mcrypt -a enigma --keymode scrypt --bare --decrypt > >> with a file containing "testing\n" and encrypted

Re: port upgrade outdated reports weird problems with deadline and poplar

> On Aug 6, 2017, at 14:59, Ryan Schmidt <ryandes...@macports.org> wrote: > > >> On Aug 4, 2017, at 20:36, Richard L. Hamilton <rlha...@smart.net> wrote: >> >> Some notes of mine on /usr/local: I can't avoid /usr/local entirely, since >> Virtua

Re: port upgrade outdated reports weird problems with deadline and poplar

Some notes of mine on /usr/local: I can't avoid /usr/local entirely, since VirtualBox and Parallels install their command line tools there. But I can move /usr/local out of the way, for the duration of MacPorts builds, as necessary. More precisely, with System Integrity Protection turned

Re: expat 2.2.2 build fail on Snow Leopard

{${os.platform} eq "darwin" && ${os.major} < 11} { >configure.cflags-append-DXML_POOR_ENTROPY=1 >} > > > On 2017-07-15, at 9:03 PM, Kenneth F. Cunningham wrote: > >> >> On 2017-07-15, at 8:36 PM, Richard L. Hamilton wrote: >> >

Re: svn server problem?

05:56, Clemens Lang <c...@macports.org> wrote: > > Hi, > > On Sat, Jul 15, 2017 at 09:06:08PM -0400, Richard L. Hamilton wrote: >> With a browser, the URL with the @## suffix seems to redirect to >> https://trac.macports.org/changeset/86927/contrib/MacPorts_Fram

Re: Portfile for audiofile trying to fetch from wrong URL

ham <ken.cunningham.web...@gmail.com> > wrote: > > Would you be interested in learning how to make a pull request to fix this up > for everyone? > > If not, perhaps you might open a ticket. > > Best, Ken > >> On Jul 12, 2017, at 7:06 AM, Richard L. Hamilton <rlha

Portfile for audiofile trying to fetch from wrong URL

---> Attempting to fetch audiofile-0.3.6.tar.gz from http://www.68k.org/~michael/audiofile/ when in fact the file is not there, but at https://audiofile.68k.org/audiofile-0.3.6.tar.gz signature.asc Description: Message signed with OpenPGP

Re: Missing /opt/local/share/man/whatis DB

Might add fc-cache to your list of programs that a port might want to run following activate/deactivate, or is that already being done as applicable? Alll this sort of thing that could be automated seems great to me, provided it doesn't extend to that which people might reasonably want to keep

Re: Missing /opt/local/share/man/whatis DB

And ideally, anything that installs (or removes) man pages from a man page directory should, after installing (or removing) the pages, run makewhatis, e.g. /usr/libexec/makewhatis /opt/local/'share/man to regenerate the index for that man page hierarchy. That would (assuming

p5.24-io-socket-ssl failed to build on Snow Leopard

This is being done under fresh re-install of MacPorts with the libcxx toolchain instructions; this is the first real choke point on getting everything I had before back, since it's needed for ImageMagick (in turn needed for other things), git, etc. version:1 :debug:main epoch: in tree: 0

exiv2 build failure on Snow Leopard

Log file attached below. Further complication with the new exiv2@0.26_0: on El Capitan, exiv2 succeeds (the missing symbol being defined there in /usr/include/pthread/pthread.h, which doesn't exist on Snow Leopard), but libextractor fails with the new exiv2, due to the following (which isn't a

Re: various errors building poppler on Snow Leopard

> On Jun 1, 2017, at 01:33, Ryan Schmidt <ryandes...@macports.org> wrote: > > >> On May 31, 2017, at 18:24, Richard L. Hamilton <rlha...@smart.net> wrote: >> >> The default compiler didn't like the option -std=c++11. When I ran with >> configure.c

tea checksum error

...when fetching it as ---> Attempting to fetch tea-44.0.0.tar.bz2 from http://semiletov.org/tea/dloads/ (which one of my systems did consistently) but fine when fetching it as ---> Attempting to fetch tea-44.0.0.tar.bz2 from https://distfiles.macports.org/tea (so I copied the good one over

Re: libzzip fails to build on Snow Leopard

#54227 > On May 24, 2017, at 03:45, Ryan Schmidt wrote: > > I don't see any open bug reports in our issue tracker for libzzip, so you > should file one. > signature.asc Description: Message signed with OpenPGP

icu build failed on Snow Leopard

version:1 :debug:main icu has no conflicts :debug:main Executing org.macports.main (icu) :debug:main dropping privileges: euid changed to 14507, egid changed to 506. :debug:archivefetch archivefetch phase started at Tue May 23 02:53:52 EDT 2017 :msg:archivefetch ---> Fetching archive for icu

Re: autogen install or upgrade fails

-autogen.txt.gz Description: GNU Zip compressed data > On May 3, 2017, at 21:52, Ryan Schmidt <ryandes...@macports.org> wrote: > > >> On May 3, 2017, at 19:15, Richard L. Hamilton <rlha...@smart.net> wrote: >> >> autogen fails rev-upgrade afte

Re: cppunit requires C++11 capable compiler now

l Capitan. > > https://trac.macports.org/ticket/54078 > > >> On May 1, 2017, at 11:41, Richard L. Hamilton <rlha...@smart.net> wrote: >> >> That was it - reverting cppunit back to @1.13.2_0 (rather than the new >> @1.14.0_0) gets rid of the rev-upgrade problem

Re: cppunit requires C++11 capable compiler now

That was it - reverting cppunit back to @1.13.2_0 (rather than the new @1.14.0_0) gets rid of the rev-upgrade problem. > On May 1, 2017, at 12:35, Richard L. Hamilton <rlha...@smart.net> wrote: > > To make it worse, a recent update (almost certainly to cppunit) causes dirac >

Re: cppunit requires C++11 capable compiler now

To make it worse, a recent update (almost certainly to cppunit) causes dirac to appear in port rev-upgrade, and then fail to build. main.log-dirac.txt.gz Description: GNU Zip compressed data > On May 1, 2017, at 12:23, Richard L. Hamilton <rlha...@smart.net> wrote: > > This

cppunit requires C++11 capable compiler now

This upgrade needed intervention to work on Snow Leopard; cppunit may not work with whatever the default compiler happens to be: configure: error: *** A compiler with support for C++11 language features is required. Workaround: port upgrade cppunit configure.compiler=macports-gcc-5

Re: gss 1.0.3 doesn't build on OS X Leopard or Snow Leopard due to use of getline()

like. > > >> On Apr 30, 2017, at 8:16 AM, Richard L. Hamilton <rlha...@smart.net> wrote: >> >> From my POV, I just want it to work, and one way is as good as another. :-) > signature.asc Description: Message signed with OpenPGP

gss 1.0.3 doesn't build on OS X Leopard or Snow Leopard due to use of getline()

Earlier versions of OS X don't provide getline(), so gss 1.0.3 won't link on those systems. Perhaps a compatibility implementation of getline() should be included and conditionally used for such cases. It might take actually linking a test program to determine whether the system provided it,

gss build fails on Snow Leopard

...because getline() is not provided by the OS (or compiler? since I don't see the symbol in libSystem.B.dylib even on Sierra). Logfile attached. On the theory that it might be the compiler, I tried port upgrade gss configure.compiler=macports-clang-3.8, but that didn't work either.

Re: Do I need +universal to be used when installing ports?

In favor of getting rid of it, the pre-built binaries (much faster to install or upgrade) aren't built +universal; so if you get rid of it, you'll often get them. Some things aren't pre-built, so you won't always get them, but it's still way faster. There may be some ports or port options

Re: Is There a Port for a compiler compatible with OpenMP and Imagemagick

Is this the sort of version cross-reference you're looking for? https://gist.github.com/yamaya/2924292 > On Apr 26, 2017, at 00:38, Ryan Schmidt wrote: > > >> On Apr 25, 2017, at 22:11, Fred Weinhaus wrote: >>

ksh93?

It hasn't built in ages, and I see a number of tickets. Has anyone looked at how Apple builds it? https://opensource.apple.com/source/ksh/ksh-23/ signature.asc Description: Message signed with OpenPGP

Re: ghostscript @9.21_0+x11 not linking properly

downgrading ghostscript? I > downgraded both just to be sure, but will reactivate ImageMagick > @6.9.8-3_0+x11 if it's working. > > On 4/24/17 3:19 AM, Richard L. Hamilton wrote: >> ghostscript@9.21_0+x11 isn't finding a shared object libgs.9.21.dylib (which >> is there in

Re: ghostscript @9.21_0+x11 not linking properly

That is of course clisp, not clips. Spelling checkers are a pain sometimes. :-) > On Apr 24, 2017, at 04:19, Richard L. Hamilton <rlha...@smart.net> wrote: > > ghostscript@9.21_0+x11 isn't finding a shared object libgs.9.21.dylib (which > is there in /opt/local/lib, so pres

ghostscript @9.21_0+x11 not linking properly

ghostscript@9.21_0+x11 isn't finding a shared object libgs.9.21.dylib (which is there in /opt/local/lib, so presumably a -L option isn't being passed?). This causes clips upgrade to fail (because it wants to use ps2pdf on a couple of its documentation files). It also seems to cause a problem

<    1   2   3   4   >