Re: How Mojave-ready is MacPorts?
On 11 Nov 2018, at 13:00, macports-users-requ...@lists.macports.org wrote: > Message: 11 > Date: Sat, 10 Nov 2018 15:27:51 -0600 > From: Ryan Schmidt > To: Dave Horsfall > Cc: MacPorts Users > Subject: Re: How Mojave-ready is MacPorts? > Message-ID: <5035eaa0-bd67-48d0-aae3-57af03245...@macports.org> > Content-Type: text/plain; charset=us-ascii > > […] > I'll probably need to write a script to pull all the failures out of the > buildbot logs, since we don't have anything set up to do that yet. If there > are ports you want to use, check whether any issues are filed against them in > Trac before upgrading the OS. > […] Whatever you write, could you add it to macports-contrib? I thought myself to pull all failures to know beforehand if and what should/could be upgraded from time to time, but it remains in my todo. It's a missing feature of MacPorts, at least for those that build from source. Is this information available throught the JSON API [1]? [1] https://build.macports.org/json/help
Re: How Mojave-ready is MacPorts?
On 12 Nov 2018, at 22:32, Ryan Schmidt wrote: > What we really want is a web site where this information can more easily be > seen. > I don't really want the public making massive numbers of http requests to the > buildmaster (which is what the script would do) I just want that every build reports its failure somewhere I can query a list of failed builds from — that should certainly not be a large one, neither number nor size. So from your answer I'll assume that I cannot get that info from the JSON API.
Re: macports-users Digest, Vol 150, Issue 4
On 4 Feb 2019, at 13:00, macports-users-requ...@lists.macports.org wrote: > Message: 5 > Date: Sun, 3 Feb 2019 20:24:48 -0800 > From: Al Varnell > To: James Linder > Cc: macports-users@lists.macports.org > Subject: Re: browser recomendations > Message-ID: <8d355b58-5608-452d-9dc8-216c6015a...@mac.com> > Content-Type: text/plain; charset="utf-8" > > I would stay away from Google Chrome. Takes up lots of room, many adware > vulnerabilities and Google tracking is alive and well. Let's throw ungoogled-chromium [1] to the pit. It's Google Chromium, sans integration with Google. [1] https://github.com/Eloston/ungoogled-chromium
Re: Ubuntu 18.04.4 on older Apple hardware
On 5 Apr 2020, at 14:00, macports-users-requ...@lists.macports.org wrote: > Message: 1 > Date: Sun, 5 Apr 2020 01:21:40 -0700 > From: Ken Cunningham > To: macports-users@lists.macports.org > Subject: Ubuntu 18.04.4 on older Apple hardware > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Although many here, including me, are focused on bringing current software to > older Apple hardware within the constraints of the software capabilities last > available on that OS version, there is another alternative; to install a > current version of linux, such as Ubuntu, on those systems. I spent some time > doing that on an older MacBook 2,1 today, and I was pleasantly surprised at > the success, in the end. > […] 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.
older lib for port
Is it feasible to maintain an older lib to compile a certain port? I wanted to update ngrep 1.45 (sourceforge) to 1.46 (github) and tried compiling in a system that had an older version of libpcap, 1.7.4 (current is 1.8.1). It worked only without the patches. It's far from ideal, but it has no maintainer and it hasn't been updated in a while, so I just thought, I might give it a try.
Re: Help wanted: unbuffer, or stdbuf
On 31 Jan 2017, at 06:47, Michael wrote: > Nope, /usr/bin. Which package installs script? util-linux
Re: Help wanted: unbuffer, or stdbuf
Both should be there port contents coreutils | grep stdb # bins are prefixed with g port contents expect | grep unbuffer On 31 Jan 2017, at 05:27, Michael wrote: > So I wanted to linebuffer a program that is feeding into a pipe. > > Looking around with Google, I found two solutions: > 1, unbuffer, from expect, or > 2, stdbuf, from the gnu core utils. > > I've got expect 5.45. I've got core utils. I don't seem to have either. > > Help please? > > --- > Entertaining minecraft videos > http://YouTube.com/keybounce >
override local port
How can I override a local portfile without deleting it? I want to keep some ports locally, for example, after I submitted a new, locally tested port that made it in the repo, or when I want to keep an older portfile until I fully tested the latest version of an application.
Re: override local port
I already have a local repo — I'd like a port in the rsync tree to exceptionally override the local one (higher preference) while keeping both in place. On 2 Feb 2017, at 14:31, Mojca Miklavec wrote: > On 2 February 2017 at 09:17, db wrote: >> How can I override a local portfile without deleting it? I want to keep some >> ports locally, for example, after I submitted a new, locally tested port >> that made it in the repo, or when I want to keep an older portfile until I >> fully tested the latest version of an application. > > You can set up multiple local repositories. If you add the second > local repository on top (with a higher preference), that other > repository will "override" the first one (in case both contain the > same port). > > One option is that you set up a local repository that consist just of > symlinks. If you want to remove a port, you just delete the symlink > and the original stays untouched where it was. > > One option is to use git manipulations (different branches and then > switching between them, merging them, cherry-picking changes, going > back to history, ...) > > Mojca
Re: override local port
On 2 Feb 2017, at 16:34, Mojca Miklavec wrote: > If you only want to do it once, you can cd to the folder with the port > that you want to use and run "sudo port ..." from there. Hmm…no, I thought I could mark the ports' default priority/availability, something like setrequested with leaves. I could use 2 local trees with rsync in second place, but that's not very practical. file:///opt/local/myports1 rsync://rsync.macports.org/release/tarballs/ports.tar [default] file:///opt/local/myports2 Or, rename the port files. In this regard, does portindex index only files named Porfile?
Re: override local port
I guess I could use a git checkout for everything. I wonder how would that work with the rsync tarball, as it seems not to be documented in the guide. Otherwise, I could parse the sources by port directory, list them, rename the Portfile I want to override and re-index. On 2 Feb 2017, at 17:24, Chris Jones wrote: > Hi, > > On 02/02/17 16:16, db wrote: >> On 2 Feb 2017, at 16:34, Mojca Miklavec wrote: >>> If you only want to do it once, you can cd to the folder with the port >>> that you want to use and run "sudo port ..." from there. >> >> Hmm…no, I thought I could mark the ports' default priority/availability, >> something like setrequested with leaves. >> >> I could use 2 local trees with rsync in second place, but that's not very >> practical. >> >> file:///opt/local/myports1 >> rsync://rsync.macports.org/release/tarballs/ports.tar [default] >> file:///opt/local/myports2 >> >> Or, rename the port files. In this regard, does portindex index only files >> named Porfile? >> > > Or switch to using a git checkout as your local repo (in which case it can be > your default, as you would have all the ports there) and then use different > git branches for the different scenarios you want. > > Renaming the files would also do it, as yes portindex only used 'Portfile' > files. > > Bottom line is there is no 'easy' way to do want you ask, so just go with > whatever works best for you. > > Chris
#53416 shc @3.9.3 : Shell Script Compiler [new submission]
Could you please review this ticket? I submitted it 8 days ago. (I already sent this message to the dev list, but got rejected since I'm not subscribed there, oh well…).
Re: override local port
On 6 Feb 2017, at 02:57, Ryan Schmidt wrote: > If you are using a git checkout of the complete ports tree (like I am), then > you have no use for the rsync tarball anymore. Not yet, but I might give it a try. Any caveats worth mentioning or adding to the guide?
new ports not showing in search
Could you tell when a new port is listed at macports.org? E.g., hstr has already been accepted but it doesn't show up. https://www.macports.org/ports.php?by=name&substr=hstr
Re: new ports not showing in search
In that case, maybe that page could hint at github's macports repo for searching. On 6 Feb 2017, at 19:56, Mojca Miklavec wrote: > On 6 February 2017 at 19:28, db wrote: >> Could you tell when a new port is listed at macports.org? >> >> E.g., hstr has already been accepted but it doesn't show up. >> >> https://www.macports.org/ports.php?by=name&substr=hstr > > Updating the website has not been deployed yet (we have some scripts > that are supposed to update the website, but they are not running > yet). > > Mojca
README vs installed documentation
Sometimes the README files from tarballs is better (re completeness/clarity) than the installed documentation. Is there any way to include them by default?
Re: README vs installed documentation
Thanks for the reference. I think this snippet could be mentioned under `4.7.3. Install Docs and Examples` in the guide, where there's already a placeholder header. On 11 Feb 2017, at 23:19, Ryan Schmidt wrote: > > On Feb 11, 2017, at 13:15, db wrote: > >> Sometimes the README files from tarballs is better (re completeness/clarity) >> than the installed documentation. Is there any way to include them by >> default? > > If a project's build system does not automatically install the readme and > other documentation files, portfile authors should make the portfile install > them, following this recipe: > > https://trac.macports.org/wiki/PortfileRecipes#doc > >
set port not to upgrade
How can I mark a port to not be upgraded by `port upgrade outdated`, for example, one that has a bug in my system version?
Re: set port not to upgrade
> You can try sudo port upgrade outdated and not Thanks, I have forgotten the syntax for that. I guess I could make an alias/function of it. > An even better feature would be a custom marking procedure that would allow a > user to “label” certain ports That would be ideal. Would it be feasible using a git checkout to manage all ports? On 14 Feb 2017, at 17:52, Carlo Tambuatco wrote: > An even better feature would be a custom marking procedure that would allow a > user to “label” certain ports such as mysetofvideoports or mysetoftexteditors > or whatever and then allow port actions to ignore or perform > operations on just those sets. You could then create your own custom > blacklist or whitelist or whatever. > > The only label that I know of right now is setrequested and unsetrequested. > > >> On Feb 14, 2017, at 10:12 AM, Richard L. Hamilton wrote: >> >> Sure would be handy if one could optionally have ports that failed to >> upgrade blacklisted (for that version only), so that “port upgrade” could >> still do everything else. >> >>> On Feb 14, 2017, at 8:15 AM, Carlo Tambuatco wrote: >>> >>> You can try sudo port upgrade outdated and not >>> >>> or >>> >>> sudo port upgrade outdated and not and not rdependentof: >>> (not sure of the exact syntax, here) >>> >>> To ignore a port and its recursive dependencies… >>> >>> >>> >>>> On Feb 14, 2017, at 6:03 AM, db wrote: >>>> >>>> How can I mark a port to not be upgraded by `port upgrade outdated`, for >>>> example, one that has a bug in my system version? >>> >> >
Re: set port not to upgrade
On 14 Feb 2017, at 23:08, Clemens Lang wrote: > If this isn't sufficient, you can keep an old copy of the port in a local > portfile repository [1], but please don't forget about that if you do it. It is not, but a local portfile seems to also override a potential upgrade. Any other ways? Should I open a feature request?
Re: set port not to upgrade
I get your point, but wouldn't a warning during build phase suffice? Be it a leaf or node the port marked to not be upgraded. As of now, if port A, a leaf, doesn't compile due to a bug in my system version, the only feasible solution is to move the working Portfile to a local repo, or use a git checkout. Or, how do you manage/rollback a broken application while updating, say, 50+ ports? I'm just curious. On 17 Feb 2017, at 01:12, Ryan Schmidt wrote: > > On Feb 15, 2017, at 15:58, Clemens Lang wrote: > >> On Wed, Feb 15, 2017 at 09:27:25AM +0100, db wrote: >>> It is not, but a local portfile seems to also override a potential >>> upgrade. >>> >>> Any other ways? Should I open a feature request? >> >> Not aware of any other ways. Feel free to open a ticket, but please >> check for an existing one first. >> >> MacPorts mode of operation also includes always upgrading dependencies >> first, so a change like this might get complicated fast. Help would be >> very welcome. > > > I don't think this a feature we could/should implement. MacPorts doesn't > currently differentiate between breaking and non-breaking port upgrades. If > we implemented this feature, and you were able to exclude port X from > upgrading, while still allowing ports P Q R S to upgrade even though they > depend on X, then this might work (if the upgrade of X you are excluding is a > non-breaking upgrade, such as a minor version upgrade), but it might cause > havoc (if the upgrade of X you are excluding is a breaking upgrade, such as a > major version upgrade that changes the library version number). We don't want > to be responsible for providing support for untangling the breakage you would > introduce in such situations. > > Instead, we should focus our energy on fixing whatever problem is preventing > you from upgrading X. >
Re: set port not to upgrade
> Really, MacPorts is designed for you to run the version of the ports that we > currently provide, not an earlier version. As I said, I do get your point. Nevertheless, I still think that something could be done. As of now I can locally duplicate a portfile, which has the effect of completely overriding the rsync tarball and not being notified of any available upgrades online. There seems to be no means to coordinate both. Let me use your example with GraphicsMagick - although the version numbers might not be accurate. Assume I have GraphicsMagick @1.3.25_2 dependent on webp @0.5.2 and that syncing shows that GraphicsMagick rev 3 and webp @0.6.0 are available. Upgrading outdated ports would start with webp from 0.5.2 to 0.6.0 and succeed, then GraphicsMagick from rev 2 to 3 and fail. If MacPorts could record working dependencies for requested ports, it could first try the steps you described by downloading the binaries, next building from source, and eventually giving the option to, and this is my thought, locally branch the recorded dependency by adding new interdependent ports webp @0.5.2_L -> GraphicsMagick @1.3.25_2_L - but on next synchronisation, it would try to upgrade GraphicsMagick's next version with webp currently @0.6.0 or its next version. It'd be like a trial and error depth search backwards and forwards to get an older or updated working binary. That said, I don't actually expect the devs to change the design of MacPorts, but search for some feasible workaround as is. I do manually maintain a couple of broken ports locally until problems are solved, and this I could automatise. In a previous message you said you use a git checkout of the complete ports tree. Although I know how it works, I barely use git and MacPorts would be a reasonable excuse for using it more often. What's your experience with it and MacPorts? Could you mention any caveats for a use case like the above? On 17 Feb 2017, at 21:54, Ryan Schmidt wrote: > > On Feb 17, 2017, at 10:13, db wrote: > >> I get your point, but wouldn't a warning during build phase suffice? Be it a >> leaf or node the port marked to not be upgraded. As of now, if port A, a >> leaf, doesn't compile due to a bug in my system version, the only feasible >> solution is to move the working Portfile to a local repo, or use a git >> checkout. > > Let's take a specific example. > > Let's suppose that you use GraphicsMagick, which links with webp. > > webp was recently updated to 0.6.0: > > https://github.com/macports/macports-ports/commit/a69f60e3695e87f628b7c7a6f2480e8e4fa056c4 > > This increased the major version number of the webp libraries. GraphicsMagick > and anything else linking with the webp libraries is now broken and must be > rebuilt. Therefore, in the next commit, I increased the revision of all such > ports: > > https://github.com/macports/macports-ports/commit/bb2433fa33857a0672c4971bd91808f804b2f673 > > Suppose that for whatever reason webp 0.6.0 did not install on your computer. > Suppose that you noticed that GraphicsMagick was outdated, and that webp's > failure was preventing GraphicsMagick from updating. Suppose that you decided > to use your hypothetical feature to induce GraphicsMagick to upgrade, despite > the fact that its dependency webp will not build. > > All possible outcomes of this situation are undesirable. > > Possibility 1. You cannot use our pre-compiled binaries for some reason, so > MacPorts builds GraphicsMagick from source against webp 0.5.2. But the entire > purpose of the update to GraphicsMagick was to rebuild it against webp 0.6.0, > so rebuilding it now against 0.5.2 again is a waste of your time. If you > later succeed in updating webp to 0.6.0, GraphicsMagick will be broken. If > you have revupgrade set to its default rebuild mode, MacPorts will then > rebuild it for webp 0.6.0. If you have revupgrade set to report or none, then > GraphicsMagick will just be broken, and you might not know why, and you might > ask us for help, which will be a waste of our time. The more time we spend > answering questions about problems the user caused for themselves by doing > things we don't recommend, the less time we have to actually work on > improving MacPorts, so we don't really want to make it easier for the user to > do things we don't recommend. > > Possibility 2. You receive a pre-compiled binary of GraphicsMagick from our > build server. It was built for webp 0.6.0, but you still have webp 0.5.2, so > the updated binary you just downloaded is considered broken, and downloading > that was a waste of your time. If you have revupgrade set to its default > rebuild mode, MacPorts will then download the source code and rebui
#53591 terminal_markdown_viewer @1.6.3 : Styled Terminal Markdown Viewer
I submitted this one about a week ago.
cleanup after selfupdate
I changed the source to git. Can I safely delete the rsync tarball and related files at /opt/local/var/macports/sources/rsync.macports.org/ ? I also upgraded to 2.4.1 using `port`. Are there any files remaining from it that could/should be deleted? I noticed that this is still using rsync.
Re: cleanup after selfupdate
What about unnecessary files from the upgrade to 2.4.1 using `port`? Up until now I always used the package, which had the consequence of writing my profile, but at least it never increased the prefix size by 1 GB. On 27 Feb 2017, at 19:16, Ryan Schmidt wrote: > > On Feb 27, 2017, at 05:08, db wrote: > >> I changed the source to git. Can I safely delete the rsync tarball and >> related files at /opt/local/var/macports/sources/rsync.macports.org/ ? > > Sure. > > >> I also upgraded to 2.4.1 using `port`. Are there any files remaining from it >> that could/should be deleted? I noticed that this is still using rsync. > > selfupdate always uses rsync. >
Re: cleanup after selfupdate
On 27 Feb 2017, at 20:48, Ryan Schmidt wrote: > What files are you referring to? > Are you claiming that something new is using up 1GB of space? Starting with 4.8 GB MacPorts prefix, I changed the source to using git and upgraded to 2.4.1 via `port` — it went up to 5.9, from which I deleted .35 rsync tarball related files. I haven't upgraded any ports yet, so I don't know where .65 come from.
Re: cleanup after selfupdate
On 27 Feb 2017, at 20:48, Ryan Schmidt wrote: > What files are you referring to? > Are you claiming that something new is using up 1GB of space? After a reboot I realised that the Finder got the folder size wrong and that after deleting the rsync tarball I actually gained meager 150 MB. In any case, port reclaim could check the sources for unused ones to clean up.
Re: Migration Assistant moved MacPorts home directories
On 2 Mar 2017, at 01:21, Brandon Allbery wrote: > In fact only one change is needed: you do some of the early steps on the > origin system instead of all of it on the destination. I've used an adjusted > version of that a few times to do migrations, including with Apple's > Migration Assistant in play. Could you elaborate?
Re: #53591 terminal_markdown_viewer @1.6.3 : Styled Terminal Markdown Viewer
Could someone take a look at this submission? https://trac.macports.org/ticket/53591 On 24 Feb 2017, at 15:16, db wrote: > I submitted this one about a week ago.
Re: Using an older port to make another port
On 5 Mar 2017, at 01:58, Michael wrote: > Ok, how? > > Is it as simple as "copy these files out of the git tree into the /opt tree"? > And if so, will that "clean up" automatically the next time I do a selfupdate? > > Is there an environment variable I can set to say "Find the portfiles here, > rather than in the default location"? My concern here is that I can easily > think of cases where turning back a library requires turning back the > programs that use that library. · installing an older version of a port in the github era -- an answer https://lists.macports.org/pipermail/macports-dev/2016-December/035058.html · set port not to upgrade https://lists.macports.org/pipermail/macports-users/2017-February/thread.html#42751 · Local Portfile Repositories https://guide.macports.org/#development.local-repositories I haven't gotten around to make it with git, nor used local libraries yet, but you could try duplicating libarchive and cmake locally and make the latter dependent on a renamed version of the former, like port:libarchive_local in its portfile. For the caveats read the threads above.
verbose output in shell mode
Is there any way to enable verbose output _after_ entering shell mode with `port`? I'd rather not use `port -v`, then I get it unnecessarily for all commands.
Re: verbose output in shell mode
Do you know of any means that I'm not aware of to make livecheck output its result without -v? On 6 Mar 2017, at 13:45, Ryan Schmidt wrote: > >> On Mar 6, 2017, at 03:46, db wrote: >> >> Is there any way to enable verbose output _after_ entering shell mode with >> `port`? I'd rather not use `port -v`, then I get it unnecessarily for all >> commands. > > Not that I know of. > >
Re: verbose output in shell mode
Try with emacs.
On 6 Mar 2017, at 14:47, Ryan Schmidt wrote:
> On Mar 6, 2017, at 07:44, db wrote:
>
>> Do you know of any means that I'm not aware of to make livecheck output its
>> result without -v?
>
>
> There doesn't seem to be any difference in livecheck output when using the
> verbose flag:
>
>
> $ port livecheck gcc7
> gcc7 seems to have been updated (port version: 7-20170226, new version:
> 7-20170305)
> $ port -v livecheck gcc7
> gcc7 seems to have been updated (port version: 7-20170226, new version:
> 7-20170305)
>
>
> Debug output of course has more to say:
>
>
> $ port -d livecheck gcc7
> DEBUG: Copying /Users/rschmidt/Library/Preferences/com.apple.dt.Xcode.plist
> to /opt/local/var/macports/home/Library/Preferences
> DEBUG: Changing to port directory:
> /Users/rschmidt/macports/macports-ports/lang/gcc7
> DEBUG: OS darwin/16.4.0 (Mac OS X 10.12) arch i386
> DEBUG: Sourcing PortGroup select 1.0 from
> /Users/rschmidt/macports/macports-ports/_resources/port1.0/group/select-1.0.tcl
> DEBUG: Sourcing PortGroup compiler_blacklist_versions 1.0 from
> /Users/rschmidt/macports/macports-ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl
> DEBUG: compiler llvm-gcc-4.2 2336.11 not blacklisted because it doesn't match
> {llvm-gcc-4.2 < 2336.1}
> DEBUG: compiler clang 800.0.42.1 not blacklisted because it doesn't match
> {clang < 300}
> DEBUG: Reading variant descriptions from
> /Users/rschmidt/macports/macports-ports/_resources/port1.0/variant_descriptions.conf
> DEBUG: universal variant already exists, so not adding the default one
> DEBUG: Requested variant -atlas is not provided by port gcc7.
> DEBUG: Requested variant +accelerate is not provided by port gcc7.
> DEBUG: Requested variant +bash_completion is not provided by port gcc7.
> DEBUG: Executing variant universal provides universal
> DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
> DEBUG: Finished running callback
> portconfigure::add_automatic_compiler_dependencies
> DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
> DEBUG: Finished running callback
> portbuild::add_automatic_buildsystem_dependencies
> DEBUG: Starting logging for gcc7
> DEBUG: Executing org.macports.main (gcc7)
> DEBUG: livecheck phase started at Mon Mar 6 07:46:35 CST 2017
> DEBUG: Executing org.macports.livecheck (gcc7)
> DEBUG: Port (livecheck) version is 7-20170226
> DEBUG: Fetching ftp://gcc.gnu.org/pub/gcc/snapshots/
> DEBUG: The regex is "LATEST-7 -> (7-[0-9]+)"
> DEBUG: The regex matched "LATEST-7 -> 7-20170305", extracted "7-20170305"
> gcc7 seems to have been updated (port version: 7-20170226, new version:
> 7-20170305)
>
>
>
Re: verbose output in shell mode
I meant try with other ports, e.g., emacs $ port livecheck emacs $ $ port -v livecheck emacs emacs seems to be up to date Not all ports give the same output with livecheck without -v. On 6 Mar 2017, at 14:54, Ryan Schmidt wrote: > On Mar 6, 2017, at 07:53, db wrote: > >> Try with emacs. > > Sorry, I've never used emacs. >
Re: verbose output in shell mode
I would expect some output without verbose flag like $ port livecheck [port] [port] seems to be up to date Not worth a feature request, I guess. On 6 Mar 2017, at 15:05, Ryan Schmidt wrote: > On Mar 6, 2017, at 08:03, db wrote: >> >> I meant try with other ports, e.g., emacs >> >> $ port livecheck emacs >> $ >> $ port -v livecheck emacs >> emacs seems to be up to date >> >> Not all ports give the same output with livecheck without -v. > > Ah, I see. Yes, when non-verbose output is empty, it's meant to indicate that > no update is believed to be available. The reasons for that might vary, and > verbose output might be more specific. >
Re: Old Mac OS X ssl issues [was Re: Trac login]
On 6 Mar 2017, at 23:29, Geoff Down wrote: > On Mon, Mar 6, 2017, at 09:51 PM, Daniel J. Luke wrote: >> On Mar 6, 2017, at 4:44 PM, Geoff Down wrote: What Mac OS X version are you on? >>> 10.4.11 .That's also why I can't access Trac via Github. >> >> IIRC macports uses libcurl linked against system openssl - so you're >> going to see this more and more often (as current security >> recommendations require ssl/tls configuration that doesn't work out of >> the box on pre-10.9). > I'm in the midle of updating curl as well. IIRC I had a similar issue with curl ≤7.40, see http://unix.stackexchange.com/a/192953/36191.
fail to destroot port with only makefile
I'm trying to port a client that comes with only a makefile, but fail to destroot it, although it sort of does if I sudo manually. I attach the log. https://github.com/tldr-pages/tldr-cpp-client/blob/master/Makefile main.log Description: Binary data
Re: fail to destroot port with only makefile
On 7 Mar 2017, at 17:29, Ryan Schmidt wrote:
> The Makefile does not support DESTDIR. Ideally, fix the Makefile to support
> DESTDIR and submit that to the developers.
MacPorts Guide links to
http://www.gnu.org/prep/standards/html_node/DESTDIR.html, where it states 'You
should not set the value of DESTDIR in your Makefile at all'. Eventually, I used
destroot.argsprefix=${destroot}${prefix}
> This question is better asked on macports-dev, since it's about developing
> ports, not using existing ports.
Sorry, I thought macports-dev was for MacPorts devs only. It's not very
practical, I'd rather get mail from topics I start, reply to or am interested
in, instead of being subscribed to 2 lists.
Re: fail to destroot port with only makefile
On 7 Mar 2017, at 20:00, Ryan Schmidt wrote:
> That can be an acceptable workaround. Sometimes it has side effects. I don't
> know if it does with this port.
Can you give an example?
Something strange I found is that file copy fails silently, no log whatsoever,
pre- and post-destroot.
post-destroot {
file copy ${worksrcpath}/autocomplete/complete.bash \
~/.tldr.complete
}
Re: fail to destroot port with only makefile
On 8 Mar 2017, at 01:10, Ryan Schmidt wrote:
>> On 7 Mar 2017, at 20:00, Ryan Schmidt wrote:
>>> That can be an acceptable workaround. Sometimes it has side effects. I
>>> don't know if it does with this port.
>
> In the destroot phase, you should not be attempting to modify anything
> outside of the ${destroot} directory. Only items in the destroot will be
> properly recorded by MacPorts as belonging to that port. I'm not certain, but
> hopefully MacPorts would prevent you from placing files outside of that
> directory.
Yeah, I don't know why I was trying to do that in the first place. Despite
this, strangely nothing was logged. I submitted the port with ticket #53753 if
you want to take a look at it. I stuck to destroot.args (checked other
portfiles, some use this, some patch makefile, not univocally), copied
autocompletion files to {prefix}/share/{subport} (checked porthier) and added
notes to copy them to a source-able location.
building from source with libc++
I use 10.8 (don't need/don't want to upgrade) and stumbled upon a couple of ports that require libc++.So I gave building from source a try in a vm following these instructions and soon encountered a couple of problems with python2_select (needed base updated) and xorg-libX11 (attached config.log), which is working fine in another system with same versions.Are there any caveats when always buildling from source in MP?Should I file a ticket for xorg-libX11? config.log Description: Binary data
Re: building from source with libc++
On 24 Mar 2017, at 16:00, Rainer Müller wrote: > A similar ticket had been filed before: > https://trac.macports.org/ticket/52335 I don't see how that explains that 1.6.4_0 in one system is the binary from MP, but this same version fails to compile in another identical system. OS X 10.8.5, Xcode 5.1.1. And neither does it help me to decide if it'd be better not to switch to compile from source and break other ports down the line.
Re: building from source with libc++
On 24 Mar 2017, at 19:23, Ryan Schmidt wrote: > I agree that ticket describes the error you encountered. It was closed > because nobody could explain it and the problem went away for the reporter. > You could re-open it and add your new information to it. Re-open #52335 while it's for different OS and Xcode versions? Fwiw, I could try building xorg-libX11 from source but with libstdc++, first.
Re: building from source with libc++
On 24 Mar 2017, at 19:21, Ryan Schmidt wrote: > Upgrading to a version of macOS with libc++ as default (10.9 and later) will > probably make your MacPorts life easier, but it's up to you of course. Despite the overall lower quality and usability of 10.9+, I don't see how, since MP in 10.8 can be configured to use libc++. >> problems with python2_select (needed base updated) > What do you mean? I don't remember the exact error, but it failed to compile — it succeeded when I upgraded the base from 2.3.x to 2.4.1. >> and xorg-libX11 (attached config.log), which is working fine in another >> system with same versions. > Another 10.8 system that you've also switched to libc++? Any differences > between the two systems you can think of? OS X 10.8.5, Xcode 5.1.1, MP 2.4.1 — no differences that come to mind. > Not really. You could run into build problems. If you do, and it doesn't seem > to be because of something unique to your system, please let us know. Should I expect to encounter problems when switching to building from source with libc++ for the same ports whose binaries work fine with libstdc++?
Re: building from source with libc++
I opened #53866, but forgot the version in the subject, @1.6.4, and the exact version of ML, which is 10.8.5 — if you can amend it for me. On 27 Mar 2017, at 05:49, Jeremy Huddleston Sequoia wrote: > libX11 has no C++ code, so the error probably has nothing to do with the C++ > library chosen. > > Please do open a ticket with whatever relevant data you can provide. > >> On Mar 24, 2017, at 14:24, Ryan Schmidt wrote: >> >> >> On Mar 24, 2017, at 14:48, db wrote: >> >>> On 24 Mar 2017, at 19:23, Ryan Schmidt wrote: >>>> I agree that ticket describes the error you encountered. It was closed >>>> because nobody could explain it and the problem went away for the >>>> reporter. You could re-open it and add your new information to it. >>> >>> Re-open #52335 while it's for different OS and Xcode versions? >> >> Or file a new ticket, making reference to the old one. It's the same error >> message, so it may well be the same cause. Or it may not. I don't know. >> >>> Fwiw, I could try building xorg-libX11 from source but with libstdc++, >>> first. >> >> There are two possibilities. 1. xorg-libX11 doesn't build when built for a >> non-default c++ stdlib. If you think this is the problem, then file a >> ticket. 2. There is a problem on your computer that prevents xorg-libX11 >> from building in any situation. If you believe that is the case, then try to >> build it with libstdc++. (We already know it builds fine with libstdc++ on >> 10.8 on our automated build system.) >> >> >>> On Mar 24, 2017, at 14:50, db wrote: >>> >>> On 24 Mar 2017, at 19:21, Ryan Schmidt wrote: >>>> Upgrading to a version of macOS with libc++ as default (10.9 and later) >>>> will probably make your MacPorts life easier, but it's up to you of course. >>> >>> Despite the overall lower quality and usability of 10.9+, I don't see how, >>> since MP in 10.8 can be configured to use libc++. >> >> I can't speak to the lower quality and usability that you perceive. I can >> only tell you that build systems are finicky things, many of them are >> nonstandard, and there are probably many of our ports that do not properly >> pass the c++ stdlib flags to the build system, which will lead to problems >> most port developers have not encountered, so you may be encountering them >> and having to help test and resolve them. >> >> >>>>> problems with python2_select (needed base updated) >>>> What do you mean? >>> >>> I don't remember the exact error, but it failed to compile — it succeeded >>> when I upgraded the base from 2.3.x to 2.4.1. >> >> Ok, probably the "-q" flag we added to reinplace in 2.4.0. We never support >> old versions of MacPorts. Always use the current version. >> >> >>>>> and xorg-libX11 (attached config.log), which is working fine in another >>>>> system with same versions. >>>> Another 10.8 system that you've also switched to libc++? Any differences >>>> between the two systems you can think of? >>> >>> OS X 10.8.5, Xcode 5.1.1, MP 2.4.1 — no differences that come to mind. >> >> If the other 10.8 system also was switched to libc++ then I would believe >> there is a problem with this system that does not exist on your other 10.8 >> system. The problem could be an older version of Xcode, or mismatched or >> missing version of the command line tools. >> >> >>>> Not really. You could run into build problems. If you do, and it doesn't >>>> seem to be because of something unique to your system, please let us know. >>> >>> Should I expect to encounter problems when switching to building from >>> source with libc++ for the same ports whose binaries work fine with >>> libstdc++? >> >> Certainly; libc++ on 10.8 is a nonstandard configuration that most MacPorts >> developers have never tested; as such, you're bound to run into >> as-yet-undiscovered problems that will need to be diagnosed and fixed by >> someone. >> >> In addition, you can run into the conflicts anyone could run into when >> building from source that can arise when building software on non-pristine >> systems. (Our binaries are produced on our buildbot system which is >> "pristine" because it has no third-party software installed and no MacPorts >> ports active when each port is built, ensuring there can be no conflicts.) >> >
Re: building from source with libc++
On 24 Mar 2017, at 22:24, Ryan Schmidt wrote: >> Should I expect to encounter problems when switching to building from source >> with libc++ for the same ports whose binaries work fine with libstdc++? > > Certainly; libc++ on 10.8 is a nonstandard configuration that most MacPorts > developers have never tested; as such, you're bound to run into > as-yet-undiscovered problems that will need to be diagnosed and fixed by > someone. > > In addition, you can run into the conflicts anyone could run into when > building from source that can arise when building software on non-pristine > systems. (Our binaries are produced on our buildbot system which is > "pristine" because it has no third-party software installed and no MacPorts > ports active when each port is built, ensuring there can be no conflicts.) Does the buildbot system have a machine with ≤10.8.5 building from source using libc++ as PoC of https://trac.macports.org/wiki/LibcxxOnOlderSystems ?
Re: building from source with libc++
On 27 Mar 2017, at 11:12, Mojca Miklavec wrote: > Dealbreaker: >https://trac.macports.org/ticket/50448 Thanks for pointing that out. I skimmed through it. What's the actual state re libc++ binaries for <10.9? Is dropping support for <10.9 something MP team is considering? As a 10.8-user, MP is for me one motive to still use Apple's platform, or at least, delay moving completely to Linux.
Re: building from source with libc++
On 28 Mar 2017, at 13:15, Rainer Müller wrote: > The support in base is missing to differentiate between binary archives > with a different cxx_stdlib. That is required to provide an upgrade path > for existing installations. May I assume that that won't happen in the foreseeable future and start building from source with libc++? > Any version of macOS older than 10.9 Mavericks is considered legacy > already. This means we do not expect maintainers to actively look into > fixing issues, but submitted patches should be accepted and applied as > long as they do not break functionality for later versions. Is there any MP official notice of support? I see builders as far back as 10.5-ppc, which I find great, although I don't use it, and probably a fair amount of laudable work.
Re: building from source with libc++
On 28 Mar 2017, at 17:31, "Daniel J. Luke" wrote: > On Mar 28, 2017, at 9:55 AM, db wrote: >> Is there any MP official notice of support? > It's right there on https://www.macports.org That is not. And one thing is targeting mainly systems still supported by Apple, another going along with it and dropping support for legacy versions and yet another building for the most compatibility, like some out there intend. These nuances are not in the link you provided.
Re: building from source with libc++
On 28 Mar 2017, at 17:42, db wrote: > On 28 Mar 2017, at 17:31, "Daniel J. Luke" wrote: >> On Mar 28, 2017, at 9:55 AM, db wrote: >>> Is there any MP official notice of support? >> It's right there on https://www.macports.org > > That is not. And one thing is targeting mainly systems still supported by > Apple, another going along with it and dropping support for legacy versions > and yet another building for the most compatibility, like some out there > intend. These nuances are not in the link you provided. Could someone from MP team shed some light on this, please?
Re: building from source with libc++
On 1 Apr 2017, at 17:24, Ken Cunningham wrote: > I am not (presently at least) on the macports team, but I have been building > all software from source with libc++ for over a year now on 10.6.8 with > outstanding success. I works extremely well for me. > ... > Not everything works --- the only limitation seems to be when software is > written against features that only exist in new MacSDKs. Thanks Ken, it's nice to read about your experience with libc++ on older systems. What I would like to know is though, how is MP team's view on legacy OS versions — I do know that it's focusing on 10.9+ supported systems, as stated in the homepage, and that here and there software is still being patched for the former and binaries still produced, but for lack of a somewhat official notice of support, I'd appreciate the views of its members. I personally find it great that software is still being compiled for older versions than what I use, as I do understand people who are stuck or willingly won't upgrade their systems. For me, the overall quality and usability has declined post 10.9 — but that's another topic.
Re: building from source with libc++
On 3 Apr 2017, at 18:09, Mojca Miklavec wrote: > Basically yes. You could follow point 3 of > https://trac.macports.org/wiki/Migration Is the script from 3.e. relevant if no particular variants were installed? I ask because I probably won't automate the whole process as I might have to check some firewall rules manually and could compile parallel to other tasks, starting with the ports I use most.
MP_EDITOR doesn't work
I set MP_EDITOR but it doesn't seem to work on base 2.4.1. VISUAL, second var MP checks according to the guide, does though.
Re: MP_EDITOR doesn't work
On 4 Apr 2017, at 11:18, Rainer Müller wrote: > How did you test this? This works fine for me: > $ export MP_EDITOR=less > $ port edit zlib export VISUAL=/opt/local/bin/vim works export MP_EDITOR=/opt/local/bin/vim doesn't
Re: Difficulty in upgrading MacPorts from El Capitan to Sierra
On 4 Apr 2017, at 09:44, Barrie Stott wrote: > 2. I would like to be able to take a requested port and find the tree of > ports that would need to be installed before this port. http://apple.stackexchange.com/questions/26921/installed-macports-packages-sizes/240638#240638
Re: MP_EDITOR doesn't work
On 4 Apr 2017, at 11:21, db wrote: > On 4 Apr 2017, at 11:18, Rainer Müller wrote: >> How did you test this? This works fine for me: >> $ export MP_EDITOR=less >> $ port edit zlib > export VISUAL=/opt/local/bin/vim works > export MP_EDITOR=/opt/local/bin/vim doesn't Could you please try it with an editor?
Re: MP_EDITOR doesn't work
On 6 Apr 2017, at 02:35, Ryan Schmidt wrote: > export EDITOR=editor.sh And does it work with MP_EDITOR? I just tried setting it in a vanilla vm, no dice. I set -dv when editing a portfile, but no related information is being logged.
Re: MP_EDITOR doesn't work
On 6 Apr 2017, at 23:10, Joshua Root wrote: > Yes it works with MP_EDITOR, I just checked. You never showed the exact > command you are running; are you using sudo? That will strip all environment > variables that are not listed in env_keep. VISUAL and EDITOR are there in the > default sudoers, but MP_EDITOR is not. I do not sudo and I did mention the commands a couple of days ago. In my bash startup file or in any shell export VISUAL=/opt/local/bin/vim works export MP_EDITOR=/opt/local/bin/vimdoesn't work I could keep using VISUAL without knowing why MP_EDITOR doesn't work in my machines, but it puzzles me.
qt5 fails to build
On 10.8.5. I don't know if #52922 is related. Should I open a ticket?
Here's the log shortened to its last lines
:info:build /opt/local/bin/clang++-mp-4.0 -c -pipe -arch x86_64
-stdlib=macports-libstdc++ -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
-mmacosx-version-min=10.8 -O2 -std=c++1z -fvisibility=hidden
-fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wdate-time -fPIC
-DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT
-DQMEDIA_AVF_CAMERA -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_NO_KEYWORDS -DQT_PLUGIN
-DQT_MULTIMEDIA_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I.
-I../../../../include/QtMultimedia/5.7.1
-I../../../../include/QtMultimedia/5.7.1/QtMultimedia -I../../../../include
-I../../../../include/QtMultimedia
-I/opt/local/libexec/qt5/lib/QtGui.framework/Headers/5.7.1
-I/opt/local/libexec/qt5/lib/QtGui.framework/Headers/5.7.1/QtGui
-I/opt/local/libexec/qt5/lib/QtGui.framework/Headers
-I/opt/local/libexec/qt5/lib/QtCore.framework/Headers/5.7.1
-I/opt/local/libexec/qt5/lib/QtCore.framework/Headers/5.7.1/QtCore
-I/opt/local/libexec/qt5/lib/QtNetwork.framework/Headers
-I/opt/local/libexec/qt5/lib/QtCore.framework/Headers -I.moc
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/OpenGL.framework/Headers
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/AGL.framework/Headers
-I/opt/local/libexec/qt5/mkspecs/macx-clang
-F/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtmultimedia/work/qtmultimedia-opensource-src-5.7.1/lib
-F/opt/local/libexec/qt5/lib -o .obj/avfcameraflashcontrol.o
avfcameraflashcontrol.mm
:info:build avfcamerautility.mm:555:92: error: property 'firstObject' not found
on object of type 'NSArray *'
:info:build AVFrameRateRange *range =
captureDevice.activeFormat.videoSupportedFrameRateRanges.firstObject;
:info:build
^
:info:build 1 error generated.
:info:build make[4]: *** [.obj/avfcamerautility.o] Error 1
:info:build make[4]: *** Waiting for unfinished jobs
:info:build make[4]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtmultimedia/work/qtmultimedia-opensource-src-5.7.1/src/plugins/avfoundation/camera'
:info:build make[3]: *** [sub-camera-make_first] Error 2
:info:build make[3]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtmultimedia/work/qtmultimedia-opensource-src-5.7.1/src/plugins/avfoundation'
:info:build make[2]: *** [sub-avfoundation-make_first] Error 2
:info:build make[2]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtmultimedia/work/qtmultimedia-opensource-src-5.7.1/src/plugins'
:info:build make[1]: *** [sub-plugins-make_first] Error 2
:info:build make[1]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtmultimedia/work/qtmultimedia-opensource-src-5.7.1/src'
:info:build make: *** [sub-src-make_first] Error 2
:info:build make: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtmultimedia/work/qtmultimedia-opensource-src-5.7.1'
:info:build Command failed: cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtmultimedia/work/qtmultimedia-opensource-src-5.7.1"
&& /usr/bin/make -j2 -w
:info:build Exit code: 2
:error:build Failed to build qt5-qtmultimedia: command execution failed
:debug:build Error code: CHILDSTATUS 85137 2
:debug:build Backtrace: command execution failed
:debug:build while executing
:debug:build "system {*}$notty {*}$nice $fullcmdstring"
:debug:build invoked from within
:debug:build "command_exec build"
:debug:build (procedure "portbuild::build_main" line 8)
:debug:build invoked from within
:debug:build "$procedure $targetname"
:debug:build Registry error: qt55-qtbase not registered as installed & active.
:error:build See
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt5/qt5-qtmultimedia/main.log
for details.
Re: qt5 fails to build
On 8 Apr 2017, at 03:18, Ryan Schmidt wrote: > That does look like the error described in #52922, but it is marked as fixed. > What version of Xcode do you have on Mountain Lion? If it's not 5.1.1, > upgrade to that, and the corresponding version of the command line tools. Xcode 5.1.1, up-to-date CLT. Do you want me to reopen #52922 and attach the main.log?
Re: building from source with libc++
On 8 Apr 2017, at 03:27, Ryan Schmidt wrote: > On Apr 1, 2017, at 09:35, db wrote: >> Could someone from MP team shed some light on this, please? > All of MacPorts is on a best-effort basis. There is no guarantee of anything. > Most of us are volunteers working on MacPorts in our spare time on whatever > limited set of hardware we happen to have at hand. Thanks for explaining that. Back to libc++. Mojca suggested: On 3 Apr 2017, at 18:09, Mojca Miklavec wrote: > Basically yes. You could follow point 3 of > https://trac.macports.org/wiki/Migration Is the script from 3.e. relevant if no particular variants were installed? I ask because I probably won't automate the whole process as I might have to check some firewall rules manually and could compile parallel to other tasks, starting with the ports I use most.
Re: qt5 fails to build
On 9 Apr 2017, at 11:38, Ryan Schmidt wrote: > I'd file a new ticket to start with, and mention #52922. Fine, #53949.
Re: building from source with libc++
On 9 Apr 2017, at 11:39, Ryan Schmidt wrote: > Whether or not you use non-default variants, you can either automate the > reinstallation of ports using the script mentioned in 3.e, or you can do it > manually. Ok, that tcl script states in the comments # Once "good enough", integrate into port I might give it a try on another machine
Re: JPortsUI has been updated
On 8 Apr 2017, at 02:28, Stephen Baber wrote: > JPortsUI has been updated due to an error when loading the port index. I get an error when launching it from systems almost identical: OS X 10.8.5, Java 1.6.0_65, port 2.4.1. One uses rsync for the tree, another uses github and shows this error message /opt/local/var/macports/sources/null/opt/local/var/macports/sources/github.com/macports/macports-ports/Portindex does not seem to exist.
Pallet requires Tcl directory
I checked #43923. Is there any workaround?
Re: Pallet requires Tcl directory
On 10 Apr 2017, at 04:55, Ryan Schmidt wrote: > Right. It's here: https://github.com/macports/pallet/tree/gsoc15-pallet It seems it'll not build on ≤10.8. Oh well… 69405b0d9bfa4671a6157827c9ec9d174bace4ef MacPorts.framework: Don't build against 10.8 SDK This should fix building MacPorts.framework with newer versions of Xcode.
Re: Pallet requires Tcl directory
On 10 Apr 2017, at 14:32, Ryan Schmidt wrote: > I haven't tried to build Pallet from the latest git source lately. Have you? Yes, I tried on OS X 10.8.5, Xcode 5.1.1. I cloned the repo and only changed target and SDK to 10.8 and manually moved the framework to ~/Library/Frameworks/. Here's a snippet of the crash report. Process: Pallet [29792] Path:/Users/USER/Desktop/Pallet.app/Contents/MacOS/Pallet Identifier: org.macports.Pallet Version: 1.0 Code Type: X86-64 (Native) Parent Process: launchd [140] User ID: 501 Date/Time: 2017-04-10 16:27:24.756 +0200 OS Version: Mac OS X 10.8.5 (12F45) Report Version: 10 Interval Since Last Report: 64558 sec Crashes Since Last Report: 27 Per-App Crashes Since Last Report: 10 Anonymous UUID: -- Crashed Thread: 5 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x VM Regions Near 0: --> __TEXT 00010356b000-000103573000 [ 32K] r-x/rwx SM=COW /Users/USER/Desktop/Pallet.app/Contents/MacOS/Pallet ... Thread 5 Crashed: 0 libtcl8.5.dylib 0x000103618bea TclMaxListLength + 32 1 libtcl8.5.dylib 0x000103619090 Tcl_SplitList + 51 2 org.macports.frameworks.macports0x000103689fe2 -[MPInterpreter arrayFromTclListAsString:] + 86 3 org.macports.frameworks.macports0x00010368a0f5 -[MPInterpreter mutableDictionaryFromTclListAsString:] + 33 4 org.macports.frameworks.macports0x00010368a0be -[MPInterpreter dictionaryFromTclListAsString:] + 33 5 org.macports.frameworks.macports0x00010368bb4f -[MPMacPorts search:caseSensitive:matchStyle:field:] + 140 6 org.macports.Pallet 0x00010356ca2c -[MPActionLauncher loadPorts] + 100 7 com.apple.Foundation0x7fff8d610562 __NSThread__main__ + 1345 8 libsystem_c.dylib 0x7fff91368772 _pthread_start + 327 9 libsystem_c.dylib 0x7fff913551a1 thread_start + 13 ...
Re: Pallet requires Tcl directory
On 11 Apr 2017, at 04:13, Ryan Schmidt wrote: > Ok. I don't see anything in the crash report that says to me that 10.8 is > unsupported. I just see a crash, which someone needs to investigate and fix. Should I add it to an existing ticket or open a new one or do nothing? Unfortunately, it has no maintainer and seems abandoned.
Re: JPortsUI has been updated
It works, thanks! I'll probably use it only for navigating the tree, so here's my feedback so far. More -> About JPortsUI… seems to trigger connections to the update sites for requested ports. This also happens when clicking on a row in the main pane for a port to show below it. Is that necessary? I'd make the buttons on the left (from 'All' to 'What's new?') the same size as those in the top row like 'Sync', also same font size, although I would keep the different colors and bold style. That would make place to move the bottom right section with radio buttons to the left — giving a more pleasant UI, with settings on the left and navigation on the right. Full screen size would be a nice addition, too, as well as adjusting the columns in the main pane. Lastly, what does 'Reset Logo Cache' anyway? The tooltip is not clear to me. I supposed JPortsUI wouldn't write any files of itself. On 11 Apr 2017, at 07:39, Stephen Baber wrote: > JPortsUI has been updated due to an error when loading a file:// > hosted port index (ex. GitHib) and an error when uninstalling ports > has been corrected. This version, 2017-04-10, can be downloaded from > https://sourceforge.net/projects/jportsui/files/ > > Feel free to submit a ticket or feature request with SourceForge's > "Tickets" navigation button or directly gmail me. Special thanks for > help from Manfred Antar and db-iamsudo!
Re: Pallet requires Tcl directory
On 11 Apr 2017, at 09:18, Ryan Schmidt wrote: > Sure, please file a new ticket; all the existing tickets seem to be about > Pallet pre-GSoC2015. Fine, #53960.
notes repeatedly showing in port session
After installing a port with notes, these show after every command during the same shell mode session on port 2.4.1. Is there any way to disable this great feature?
port-depgraph warning
Without arguments shows this warning $ port-depgraph Warning: It looks like your PortIndex file for file:///opt/local/myports may be corrupt. Warning: It looks like your PortIndex file for file:///opt/local/var/macports/sources/github.com/macports/macports-ports/ may be corrupt. Error: : syntax error in line 1 near 'Warning'
Re: notes repeatedly showing in port session
On 12 Apr 2017, at 01:19, Ryan Schmidt wrote: > That sounds like a bug. We probably didn't test the change with shell mode. #53967, I hope I filed it correctly.
Re: notes repeatedly showing in port session
On 12 Apr 2017, at 11:02, db wrote: > On 12 Apr 2017, at 01:19, Ryan Schmidt wrote: >> That sounds like a bug. We probably didn't test the change with shell mode. > #53967, I hope I filed it correctly. That was quickly fixed. Should it be fine if I replace the binary, right?
Re: port-depgraph warning
On 11 Apr 2017, at 22:36, db wrote:
> Without arguments shows this warning
>
> $ port-depgraph
> Warning: It looks like your PortIndex file for file:///opt/local/myports may
> be corrupt.
> Warning: It looks like your PortIndex file for
> file:///opt/local/var/macports/sources/github.com/macports/macports-ports/
> may be corrupt.
> Error: : syntax error in line 1 near 'Warning'
I realised that I have port-depgraph aliased, so running it without args throws
that warning.
alias port-depgraph=' _() { port-depgraph "$1" | dot -T png -o
"$1"_depgraph.png ; } ; _ '
Re: notes repeatedly showing in port session
On 12 Apr 2017, at 16:21, Ryan Schmidt wrote: > If you want to get this fix right now, before the next version of MacPorts is > released, the official way would be to check out the master of the repository > and build the whole thing from source. Oh well…from what I gathered in history, last fixes shouldn't hinder port.tcl from working correctly, so I just renamed it as a backup in place and use the last one from GH. The notes bug was driving me nuts.
Re: port-depgraph warning
On 13 Apr 2017, at 17:38, Rainer Müller wrote: > You are effectively running it with an empty argument, which is not a valid > port name: > $ port-depgraph "" > That could indeed be handled more graceful. The source can be found here > after the move to GitHub: > https://github.com/macports/macports-contrib/tree/master/port-depgraph I also noticed the svn url in the portfile.
Re: port-depgraph warning
On 14 Apr 2017, at 01:59, Ryan Schmidt wrote: > Sure. That's still valid. There haven't been any changes in port-depgraph > since we moved to GitHub so there's no particular advantage to switching the > portfile to GitHub yet. I think the tcl script should be in base, the python script might be a separate port. Latter produces spatially more balanced graphs, sometimes.
Re: building from source with libc++
I filed #53994, #53995, #53996 for highlight, nmap and ostinato respectively, failing to build with libc++. I'd appreciate if anyone could peek at the logs and recognize a pattern or tell these are unrelated.
port leaf becoming requested
I wanted to install texinfo which is actually a leaf of coreutils, but `sudo port install texinfo` doesn't make it a requested port, as I would expect. Is it intended behaviour? I suppose, I could either uninstall leaves and reinstall it, or use setrequested.
Re: port leaf becoming requested
On 18 Apr 2017, at 13:07, Ryan Schmidt wrote: > Yes, installing a port should mark it requested. I'm unclear what happened in > your situation. This is what I do: Last login: Tue Apr 18 14:14:12 on ttys001 tests-mac:~ test$ tests-mac:~ test$ port version Version: 2.4.1 tests-mac:~ test$ tests-mac:~ test$ uname -a Darwin tests-mac.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64 tests-mac:~ test$ tests-mac:~ test$ port installed texinfo None of the specified ports are installed. tests-mac:~ test$ tests-mac:~ test$ sudo port install coreutils ---> Computing dependencies for coreutils The following dependencies will be installed: texinfo Continue? [Y/n]: y ---> Fetching distfiles for texinfo ---> Verifying checksums for texinfo ---> Extracting texinfo ---> Configuring texinfo ---> Building texinfo ---> Staging texinfo into destroot ---> Installing texinfo @6.3_0 ---> Activating texinfo @6.3_0 ---> Cleaning texinfo ---> Fetching distfiles for coreutils ---> Verifying checksums for coreutils ---> Extracting coreutils ---> Applying patches to coreutils ---> Configuring coreutils ---> Building coreutils ---> Staging coreutils into destroot ---> Installing coreutils @8.27_0 ---> Activating coreutils @8.27_0 ---> Cleaning coreutils ---> Updating database of binaries ---> Scanning binaries for linking errors ---> No broken files found. ---> Some of the ports you installed have notes: coreutils has the following notes: The tools provided by GNU coreutils are prefixed with the character 'g' by default to distinguish them from the BSD commands. For example, cp becomes gcp and ls becomes gls. If you want to use the GNU tools by default, add this directory to the front of your PATH environment variable: /opt/local/libexec/gnubin/ tests-mac:~ test$ tests-mac:~ test$ port installed texinfo The following ports are currently installed: texinfo @6.3_0 (active) tests-mac:~ test$ tests-mac:~ test$ port echo leaves | grep tex texinfo@6.3_0 tests-mac:~ test$ tests-mac:~ test$ sudo port install texinfo Password: ---> Computing dependencies for texinfo ---> Cleaning texinfo ---> Scanning binaries for linking errors ---> No broken files found. tests-mac:~ test$ tests-mac:~ test$ port echo leaves | grep tex texinfo@6.3_0 tests-mac:~ test$ tests-mac:~ test$ port echo requested coreutils @8.27_0 tests-mac:~ test$
Re: port leaf becoming requested
On 18 Apr 2017, at 14:43, Ryan Schmidt wrote: > Ok fine. So texinfo got installed as a dependency of coreutils. You didn't > ask for it directly, so it was not marked requested. > Then, after that, you asked MacPorts to directly install texinfo. Since it > was already installed, MacPorts did nothing. > If you want to mark an already-installed port requested, use "port > setrequested". I thought `port install` of a leaf port would mark it as installed and be MacPorts expected behaviour. Anyway, something to take into account when automating an installation.
Re: building from source with libc++
On 18 Apr 2017, at 09:50, db wrote: > I filed #53994, #53995, #53996 for highlight, nmap and ostinato respectively, > failing to build with libc++. I'd appreciate if anyone could peek at the logs > and recognize a pattern or tell these are unrelated. highlight (#53994) and nmap (#53995) build with sudo port install [port] configure.cxxflags="-stdlib=libc++" configure.cxx="clang++ -stdlib=libc++" How do you emend a port file to take libc++ into account when this is the default?
Re: building from source with libc++
Thanks Ken for the detailed post. On 18 Apr 2017, at 17:45, Ken Cunningham wrote: > There are two issues: > 1. cxx11 features required. > ... > Although you could say the Portfiles should all be updated as this is > recognized, it is in the end MUCH easier to install a modern compiler on your > system (say clang-3.8 or clang-3.9) and set that as the default compiler in > macports.conf. Then you will use that as your default compiler and never see > these errors either. Clang's versioning seems not consistent. $ clang --version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin12.6.0 Thread model: posix Does this mean that I have 3.4 or something around that time of release? What exact port should then I install in order to have a modern compiler as you suggest? llvm-4.0 or clang-4.0? And which configuration in macports.conf? I don't seem to find the right option in the guide, https://guide.macports.org/chunked/internals.configuration-files.html. > 2. properly setting the standard c++ library. I'm now always building from source with libc++. If I change compiler, what are the odds that I run into some other oddities with the installed ports built with the default compiler?
Re: building from source with libc++
On 19 Apr 2017, at 10:13, Mojca Miklavec wrote: > https://trac.macports.org/wiki/XcodeVersionInfo That doesn't tell me anything different from the output I posted. I still don't exactly know which clang version I have. > You would run into problems if you installed/built existing ports against > libstdc++ and want to build everything against libc++ from now on. In that > case you should start from scratch and follow migration instructions. I already reinstalled everything from scratch with libc++.
Re: building from source with libc++
On 19 Apr 2017, at 10:59, Chris Jones wrote: > You cannot really compare the stock LLVM/Clang releases to the Apple versions. I read https://trac.macports.org/wiki/UsingTheRightCompiler and this comment from Rainer, I guess, https://superuser.com/a/130474 and thus I'm not quite sure if this change would not open another can of worms. Re the exact port, I suppose it'd be clang-3.9 or clang-4.0 and configure it with clang_select? I couldn't find an option in macports.conf yet, neither in the file itself, nor somewhere else mentioned.
Re: building from source with libc++
On 19 Apr 2017, at 18:22, Ken Cunningham wrote: > You're right, that option is not listed there. It is listed in the > LibCxxOnOlderSystems instructions, which is where I originally found it. > It looks like this, in macports.conf on my system. > default_compilers macports-clang-3.8 Are the other steps described in the LibcxxOnOlderSystems instructions for 10.6 not necessary for 10.8? > You can fix these ports by manually adding -stdlib=libc++ to the CXXFLAGS > and often LDFLAGS (as you described before), and/or you can change the > default stdlib to libc++ in clang-3.8 (as I mentioned with my clang patch > before), or alternatively Mojca's idea to add the stdlib spec to the CXX > compiler environment variable would work as well, if that is implemented. > The easiest of these for me was the clang-3.8 patch. If I understood correctly Apple's clang natively does what stock clang needs to be patched for. Both 3.8 and 3.9 are at rev 3 but I'd rather assume I could patch llvm portfile manually and use your patch file 999.
Re: building from source with libc++
On 20 Apr 2017, at 00:13, Ken Cunningham wrote: > I think the Lion and Mountain Lion LibCxxOnOlderSystems instructions could > probably suggest/recommend installing and setting the default compiler to > something newer, but I defer to the gurus here. After skimming the instructions for 10.6, those for 10.8 don't seem consistent. > clang (macports-installed versions) looks at the build line it’s asked to > compile. > However, if clang doesn’t see -stdlib specified on the build line, as shipped > it will automatically add -stdlib=libstdc++ on < 10.9, and -stdlib=libc++ on > 10.9+. Then macports-installed versions could perfectly add -stdlib=libc++ if the system has libc++ installed, as in 10.8 the case is. > The few times I tried sending -stdlib=libc++ to the system installed clang > version when building with xcode on 10.6, it just generated an error saying I > had used the wrong stdlib …. so I don’t think you can override that > behaviour. I haven’t explored that much. I occasionally use Xcode directly — what is its default behaviour regarding the default compiler, is something I'd like to know. I see the suffix -3.* overall and no links, so I guess it shouldn't conflict with it. >> Both 3.8 and 3.9 are at rev 3 but I'd rather assume I could patch llvm >> portfile manually and use your patch file 999. > The patch should work just the same unless that one file has been > significantly changed (doubt it). If so, the patch phase of the port build > will error out. I checked out bb3b700f76 from macports-ports and then modified the portfile and used your diff, as the current portfile for 3.9 is llvm-3.9 @3.9.1_3, and it's changed. Both highlight and nmap installed right away. Only nuisances I found until now are a warning doubly output on each install command $ sudo port install highlight Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option ---> Computing dependencies for highlight ... and the following line is added to each port, even those that don't need it Build Dependencies: clang-3.9
Re: building from source with libc++
On 20 Apr 2017, at 19:01, Ken Cunningham wrote: > Now to be fair, IF you get a build problem, there are increased expectations > on you to check into it before you file a ticket about it. Specifically, try > to build it with a stock clang compiler and see if that builds your port. If > that does fix the build, please don't report it as a ticket - that would not > be fair to anyone. Now that I know better, I can close those tickets and post a solution thanks to you. Could you please tell me if you see the warning I mentionend and the following line in every `port info` result? Build Dependencies: clang-3.x
Re: building from source with libc++
On 20 Apr 2017, at 20:06, Ken Cunningham wrote: > On 2017-04-20, at 10:42 AM, db wrote: >> Could you please tell me if you see the warning I mentionend and the >> following line in every `port info` result? >> Build Dependencies: clang-3.x > Yes i do see that too - because of the way you've set your default compiler > to be clang-3.9, it has become a build dependency for every port. > Macports will check that it's installed and active prior to building a port. Thanks so far, Ken. Could anyone of the MP devs tell if this warning is a bug? `port rdeps` now lists clang-3.9 and so does `port space`, giving the wrong size even for a port that's just composed of a couple shell scripts.
Re: building from source with libc++
On 20 Apr 2017, at 22:54, Ken Cunningham wrote: > You’ve made clang-3.9 a build dep for everything by setting the default > compiler to clang-3.9. It will always be listed, for all ports. I often check dependencies and sizes with a couple of functions and these are now a mess. I suppose I could work around it, but nonetheless think that this lacks a rationale. > It’s the way macports works. If you could point me to the code that sets that, I'd certainly appreciate it.
Re: fullscreen multiwindow OS X bug?
On 20 Apr 2017, at 19:21, René J.V. Bertin wrote: > I ran into what looks to be a bug in Apple's fullscreen algorithms. On 10.9.5 > with screens DO NOT have separate spaces: > ... > Same happens with a Qt-based console emulator so this is not a bug in > Terminal.app . I couldn't reproduce it on 10.8.5. Have you tried switching between the windows using the Window menu or ⌘1, ⌘2, etc?
binutils warning
I thought of upgrading strings and found it in binutils. During installation a warning showed which doesn't seem to hold true at least from inspecting the contents tracked by port command, and the notes advise to uninstall it. It has no maintainer. Any ideas? [test/Desktop] > install binutils ---> Computing dependencies for binutils ---> Fetching distfiles for binutils ---> Attempting to fetch binutils-2.28.tar.bz2 from ftp://ftp.lip6.fr/pub/gnu/binutils ---> Verifying checksums for binutils ---> Extracting binutils ---> Configuring binutils ---> Building binutils ---> Staging binutils into destroot Warning: binutils installs files outside the common directory structure. ---> Installing binutils @2.28_0 ---> Activating binutils @2.28_0 ---> Cleaning binutils ---> Updating database of binaries ---> Scanning binaries for linking errors ---> No broken files found. ---> Some of the ports you installed have notes: binutils has the following notes: Having binutils installed will cause some other ports to fail to build. Consider uninstalling binutils. [test/Desktop] >
Re: binutils warning
On 22 Apr 2017, at 16:16, Rainer Müller wrote: > As identified by going back in history with 'git blame': > https://trac.macports.org/changeset/67114 Is that still the case? binutils' binaries are prepended with g like those from coreutils — and there's no gnubin dir.
qt5 build dependency on clang
On a 10.8.5-system with default compiler qt5 @5.7.1 and qt56 @5.6.2 require clang-4.0 to build, while another whose compiler is set to clang-3.9 shows this as dependency. Can anyone confirm the former?
Re: qt5 build dependency on clang
On 22 Apr 2017, at 21:27, Ken Cunningham wrote: > For your other situation where the cxx_stdlib has been set to libc++, this > whitelisting will not be forced Why not? I'm missing something.
Re: qt5 build dependency on clang
On 22 Apr 2017, at 21:58, Ryan Schmidt wrote: > Sounds plausible. What's your question / problem with this? Ken already point me to cxx11-1.1.tcl, but I still don't get why 4.0 isn't whitelisted in a system whose default is set to 3.9.
Re: binutils warning
On 22 Apr 2017, at 20:21, Ryan Schmidt wrote: > Feel free to re-test the ports that failed to build back then that caused us > to add that warning. #22539 atlas (also #22674) -> it built for hours and I didn't let it finish, sorry #22679 wine-crossover-games -> couldn't find a port by that name #24617 i386-elf-binutils-> it built without error
Re: binutils warning
On 24 Apr 2017, at 21:24, Ryan Schmidt wrote: >> On Apr 24, 2017, at 14:22, db wrote: >> #22539 atlas (also #22674) -> it built for hours and I didn't let it >> finish, sorry > Yes atlas takes hours to build. This one I won't try any further. >> #22679 wine-crossover-games -> couldn't find a port by that name > Replaced by wine-crossover. It built and run. >> #24617 i386-elf-binutils-> it built without error Bintutils' notes could have referenced more accurately these tickets. The warning doesn't seem to be actual any longer.
Re: qt5 build dependency on clang
On 22 Apr 2017, at 23:05, Ken Cunningham wrote: > because cxx_stdlib will equal libc++ and therefore this test (which would > lead to the code that does the whitelisting) will fail. Bear with me — what I actually had in mind was, since we have LibcxxOnOlderSystems instructions, why doesn't it explicitly test against libc++?
