Re: git fetch fails because of gnutls_handshake
On Sat, 29 Oct 2016, Chris Jones wrote: > On 29 Oct 2016, at 4:27 pm, Lawrence Velázquez <lar...@macports.org> wrote: [...] > > Our Trac has never automatically subscribed anyone except ticket > > reporters. Owners and Cc need to be set explicitly. I don't know if > > other projects do things differently. > > I have fallen foul of this a few times, as pretty much all other issue > tracking systems i have used indeed automatically adds anyone who sends > a reply, to receive any future comments. Trac is a bit odd i would say > in this regard to not do this. > > But its true trac has never done this, so its not a recent change. Though if the new "Cc me" button were any smaller, it would be considered a web bug. :-) Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port:qt5 and (proposed) port:qt5-kde cohabitation
On Sun, 23 Oct 2016, Clemens Lang wrote: > On Sun, Oct 23, 2016 at 11:25:52AM +0200, René J.V. Bertin wrote: > > > I noticed it for Trac (which isn't a complete improvement *). I'm not > > aware that git allows pulling only changes to a single subdirectory > > like svn does (svn up in a port dir. to update only that port, for > > instance). Does it? > > No it doesn't. It's something you'll have to live with. Actually it does. You can do: git checkout <commit, branch, etc.> -- In this case, you'd probably want "master" for the first argument. This updates the index as well as the working directory, so "git diff" without "--cached" won't show anything (but "git status" will). If you want to unstage the changes, just do : git reset This reverts the index changes so that the changes are only in the working directory. It's not clear whether doing this with or without the reset is better as an "svn analogy", given that svn doesn't have an index. Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Commit request https://trac.macports.org/ticket/52546
On Mon, 17 Oct 2016, Ken Cunningham wrote: > For your consideration -- I'd commit this as it stands and fix the port, > rather than spend too much more time on it. > > https://trac.macports.org/ticket/52546 > > I notice something has changed in the sierra time functions -- a couple of > ports seem to have time-related errors. Presumably this is because Apple has finally gotten around to implementing clock_gettime() in Sierra, and that's colliding with some locally-provided replacements. Typically a configure script would determine whether clock_gettime() is available, or whether to provide a replacement. Making that work properly is better than just commenting out the colliding typedef. Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: advanced bash-ing for long compiles
On Fri, 14 Oct 2016, Ryan Schmidt wrote:
> On Oct 14, 2016, at 09:50, Ken Cunningham <ken.cunningham.web...@gmail.com>
> wrote:
> > Oh, one more similar question while I'm at it.
> >
> > I notice mdworker seems to go nuts during these long builds, often
> > appearing to soak up lots of cycles. I assume it's trying to index
> > all the build files, etc
> >
> > is it easy to sleep that function and then re-enable it after the compile
> > is done?
>
> I configure Spotlight not to index the /opt/local/var/macports/build
> directory (System Preferences)
By default, this isn't possible via the GUI, due to the macports
directory's being hidden.
On Sat, 15 Oct 2016, Joshua Root wrote:
> Not sure why this would be, since we set the hidden flag on
> ${prefix}/var/macports (technically $portdbpath) which should exclude it
> from Spotlight indexing. Maybe that doesn't work on 10.6? You could try
> adding it to the Privacy list in the Spotlight settings manually.
If you can. See above.
One can also accomplish this via:
sudo touch /opt/local/var/macports/build/.metadata_never_index
Though I don't know if this works across all OS versions.
Hiding the macports directory also gets in the way of attaching build logs
to tickets, since the browser's dialog box can't navigate to them. I've
unhid this directory in the past for that reason, but every so often
something "fixes" it. If preventing indexing is the sole reason for
hiding the directory, wouldn't using ".metadata_never_index" be better?
Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: gdb (Re: lldb ...)
On Thu, 1 Sep 2016, [ISO-8859-1] René J.V. Bertin wrote: > On Wednesday August 31 2016 17:29:54 Lawrence Velázquez wrote: > > >The gdb port instructs the user to modify a system LaunchDaemon to > >effectively circumvent taskgated. I frankly think that's an awful idea, > >and future ports should not follow its example. > > They certainly shouldn't if there are other ways to get the software to work. > > As to gdb, is it even possible to make it work normally? Last times I > tried gdb it was at least crippled for code written in C++. > > I'm tempted to say that as long as gdb cannot be a true alternative to > lldb there's little point in maintaining the port if in addition it > requires users to do all kinds of unhealthy things. It's not like it's > particularly difficult to build gdb (for the port's target audience at > least). It's still quite useful to have gdb for cross-debugging in cases where the relevant stub/server is for gdb rather than lldb. Although lldb in principle works with the gdb stub, it expects to get a machine description from the stub that's not present in the gdb case. There's an alternative way to supply the MD to lldb as a Python module (if it exists for the relevant architecture), but my experience with that approach has been less than satisfactory, and I didn't take the time to track down why. I don't think the cross-debugging case should require any interactions with taskgated, so any mention of taskgated tweaking should probably say that it's only needed for *local* debugging. At least the taskgated tweak doesn't open anywhere near as big a security hole as what you need to do to run your own kexts on >=10.10. :-) Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port only builds with build_arch=i386 on command line -- any way to specify that in the portfile?
On Mon, 5 Sep 2016, Brandon Allbery wrote: > On Mon, Sep 5, 2016 at 8:10 PM, Fred Wright <f...@fwright.net> wrote: > > > But when they switched to Intel, they also switched > > to -O2. This allowed them to inflate the performance benefit of the > > architecture switch. :-) > > > > ...as long as -O2 worked. Experience from FreeBSD and from early MacPorts > experiments with -O2 is that it took -O2 a long time to actually generate > correct code in a majority of cases. > That said, it might be worth looking at again --- but, -O2 reportedly still > causes occasional problems for some programs, so be ready to bail back to > -Os. Interesting, given that the Linux kernel *requires* optimization to build correctly, due to some issue with macros vs. inline functions. Of course that's gcc, not clang, and it doesn't necessarily rule out -Os. It is unfortunate for debugging, since, gdb's claims to be able to debug optimized code notwithstanding, it's seriously deficient at it. On Mon, 5 Sep 2016, Ken Cunningham wrote: > This website reference says -Os and -O2 are identical: > > <http://stackoverflow.com/questions/15548023/clang-optimization-levels That's not necessarily true of all compilers, though, so I'd use -Os where size is important and -O2 (or greater) where speed is important. I suspect that the only reason -O2 and -Os are equivalent in clang is that they decided that nobody cares about code size any more. :-) BTW, the original poster on that page mistakenly thinks that the "s" is for speed. Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port only builds with build_arch=i386 on command line -- any way to specify that in the portfile?
On Sat, 3 Sep 2016, Ryan Schmidt wrote: > But only do this if this software requires it. Otherwise, let MacPorts use > its default value of -Os. Seriously? In this day and age? AIUI, Apple used to use -Os for their own builds in the PPC era, since it was needed to keep the bloat down to a dull roar in relation to disk drives at the time. But when they switched to Intel, they also switched to -O2. This allowed them to inflate the performance benefit of the architecture switch. :-) Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to use git
On Sat, 20 Aug 2016, Ian Wadham wrote: > On 20/08/2016, at 1:24 PM, Lawrence Vel�zquez wrote: > > We'll actually be using svn2git for the migration, so in a very real sense > > we have you (collectively) to thank :) > > > > https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git That was broken for a while, though it seems to be back now. There are multiple articles kicking around on possible migration issues, e.g.: Migrating from Subversion to Git and the Lessons Learned | Dr Dobb's http://www.drdobbs.com/architecture-and-design/migrating-from-subversion-to-git-and-the/240009175 Don't do svn-to-git repository conversions with git-svn! | Armed and ... http://esr.ibiblio.org/?p=6778 > I don't know if this applies to Macports, but KDE did a lot of splitting of > SVN > "module" repositories into individual project repositories on git. For > example, > the KDE Games module on SVN went from one repository to about 40 repositories: > one for each game and library. This was to limit the overheads, for > developers, > of cloning git repositories in their local machines, but it made building > "everything" > (i.e. collections of repositories) a little harder. Given that git has the ability to make "shallow" clones (with the --depth argument), this doesn't seem like a very good reason to split things up and make nontrivial cloning *more* hassle. Disclaimer: I've never bothered using this feature myself, since I have plenty of disk space and a fast net connection. :-) Git also has a "submodule" feature, but it was added as an afterthought and in the one project I've contributed to that uses it (OSXFUSE), it's been more trouble than it's worth. On Sat, 20 Aug 2016, Brandon Allbery wrote: > On Sat, Aug 20, 2016 at 11:44 PM, Ian Wadham <iandw...@gmail.com> wrote: > > > Fork the repo?? > > > github expects you to do this, yes. I don't actually recommend it because > keeping up to date with the original repo's a PITA (and *not* automated in > any way. https://help.github.com/articles/syncing-a-fork/ is annoyingly Umm, the whole merging aspect is something you need to do regardless of whether you're pulling from "origin" or "upstream", so this isn't a good argument against using a fork. It gets more complicated with multiple branches, but again the merging part is the same whether you're using a fork or not, and the only difference is whether you also need to push the merged branches to the fork. Meanwhile, the whole pull request mechanism is designed around the forked repo model, so anyone without direct commit access should be strongly encouraged to use a fork. And even for someone *with* direct commit access, a fork provides a backed-up sandbox for changes that aren't ready for the main repo (even in a branch). There's a slight difference in whether you need to specify "upstream" in the "fetch" or "pull" (since you don't normally want to make "upstream" the default remote), but that's pretty minor. > manual). You lose the ability to maintain your clone with github's web > interface, but that's not much of a loss really. (Or you can do their thing > in reverse: clone the repo, add github as an additional upstream, create a > new empty repo (not a fork) via their web interface, push to github > periodically as a backup.) You *can* do that, but it doesn't really simplify anything, so it's mainly only useful in cases where the main repo isn't hosted on GitHub (and hence where "fork" is meaningless). BTW, it's worth mentioning that "fetch" doesn't touch the working directory or index at all, so it can safely be done at any time. Then after fetching, all the fetched commits are available locally for examination, diffing, etc. Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to discontinue ports completely (py26 deprecation) ...
On Sat, 13 Aug 2016, Christopher Jones wrote: > > On 12 Aug 2016, at 11:30 pm, Fred Wright <f...@fwright.net> wrote: > > On Fri, 12 Aug 2016, Chris Jones wrote: > >> On 11/08/16 20:40, Fred Wright wrote: > > [...] > >>> Well, leaving something alone that's working just fine is hardly much of a > >>> maintenance burden. > >> > >> On the other hand, whats the rationale for keeping 2.6, given 2.7 is the > >> official upstream production version of the 2.x series. What use case > >> requires 2.6 and cannot move to 2.7 ? > > > > Testing code against 2.6 (among others), because it's intended to run on a > > wide range of platforms, and one wants to make as few assumptions as > > possible about what Python version(s) the end user might have installed. > > Some distros lag *way* behind in versions of various things, including > > Python. > > > > If the python.org folks had their way, all 2.x versions would be > > eradicated, but there were too many pitchforks at the gates to let that > > happen. :-) > > I agree there is no way to migrate completely to 3.x, but I am still not > really convinced keeping both the 2.6 and 2.7 versions in MacPorts is > worth the effort. 2.6 needs to be dropped sometime... Given that the effort involved in keeping it is zero, and the effort involved in removing it is nonzero, I don't think the "effort" argument really flies. I mainly mentioned 3.x as an illustration of how different people have different opinions as to when older versions of something should be abandoned, often for good reasons. Apple declared PowerMacs obsolete a decade ago, but some of us still have some that work, and which still get used for testing PowerPC code. :-) As I said, the main value of 2.6 is for testing. If I publish code that claims to be compatible with 2.6, then that means I've actually tested it with 2.6. And *I* don't want to tell people running 2.6 that they have to upgrade unless there's a good reason for it. Even upgrading to a nominally compatible new version may involve a lot of testing to be sure it really doesn't break anything. Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to discontinue ports completely (py26 deprecation) ...
On Fri, 12 Aug 2016, Chris Jones wrote: > On 11/08/16 20:40, Fred Wright wrote: [...] > > Well, leaving something alone that's working just fine is hardly much of a > > maintenance burden. > > On the other hand, whats the rationale for keeping 2.6, given 2.7 is the > official upstream production version of the 2.x series. What use case > requires 2.6 and cannot move to 2.7 ? Testing code against 2.6 (among others), because it's intended to run on a wide range of platforms, and one wants to make as few assumptions as possible about what Python version(s) the end user might have installed. Some distros lag *way* behind in versions of various things, including Python. If the python.org folks had their way, all 2.x versions would be eradicated, but there were too many pitchforks at the gates to let that happen. :-) Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to discontinue ports completely (py26 deprecation) ...
On Thu, 11 Aug 2016, Lawrence Velázquez wrote: > > On Aug 11, 2016, at 3:40 PM, Fred Wright <f...@fwright.net> wrote: > > > > Well, leaving something alone that's working just fine is hardly much > > of a maintenance burden. > > As Josh noted, this approach is fine for CPython itself, but less so > for modules. As they work to keep their modules up to date, maintainers > can hardly be expected to support subports for Python versions that > don't build on recent OSes (although they are certainly welcome to if > they wish). But often the subports work fine as well. For example, here I have local versions of seven py-xxx ports just to expand the version lists. In five of the cases, expanding the version lists "just worked". The other two ports each had a set of version-specific files (for no obvious reason, given the content) which just needed to be trivially and obviously expanded for the added versions. Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to discontinue ports completely (py26 deprecation) ...
On Wed, 10 Aug 2016, Lawrence Velázquez wrote: > On Aug 10, 2016, at 5:21 PM, Fred Wright <f...@fwright.net> wrote: > > > I don't consider Python 2.6 to be "cruft". Developers need many > > versions of Python installed for testing, and that includes any > > packages that are also needed. It's annoying to have to create local > > versions of portfiles solely to add versions that are missing for no > > substantive reason. > > The substantive reason is that every additional version of CPython we > support is a maintenance burden, especially one that saw its last > feature release 6 years ago and its last bugfix release nearly 3 years > ago. Well, leaving something alone that's working just fine is hardly much of a maintenance burden. BTW, there's some erroneous information that making code compatible with both Python 2 and Python 3 requires 2.7. I have yet to encounter any issues with "polyglot" code per se on Python 2.6. Anything earlier is definitely problematic, however. Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to discontinue ports completely (py26 deprecation) ...
On Wed, 10 Aug 2016, Sterling Smith wrote: > I am all in favor of removing cruft. However, would it be worthwhile to > ping the user email list about the ports that will be deprecated (give a > specific list), to see if anyone will complain, or is it better to just > remove them, and then when someone complains tell them how to go back to > an old version of a Port? I don't consider Python 2.6 to be "cruft". Developers need many versions of Python installed for testing, and that includes any packages that are also needed. It's annoying to have to create local versions of portfiles solely to add versions that are missing for no substantive reason. Python 2.6 here: MacPro:~ fw$ port installed|egrep 'py(|thon)26' py26-cairo @1.10.0_3 (active) py26-pip @8.1.2_0 (active) py26-readline @6.2.4.1_1 (active) py26-setuptools @25.1.0_0 (active) python26 @2.6.9_4 (active) Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Signing packages without violating restrictions/laws
On Mon, 18 Apr 2016, Mojca Miklavec wrote: > This seems to be a problem for GPG though. Apparently USA export > restrictions forbid exporting software that does cryptography (and > some other countries might have import restrictions). That's largely ancient history. > I have a problem understanding those rules because we are not dealing > with encrypted information, but merely use the same algorithms to > verify authenticity of the packages. On the other hand I have problems > believing that this problem really cannot be solved ... MacPorts > apparently solved it. Even in the days of the draconian export restrictions: 1) Export of *signing* software was permitted. Though since signatures are basically encrypted hashes, it could get "interesting" to determine whether a given piece of software complied. 2) Export of encryption software was allowed, provided that it had a sufficiently limited key size, e.g. 40-bit "export grade" keys. 3) That nonsense was mostly eliminated in 2000. See, e.g.: http://www.crypto.com/exports/ Nevertheless, the damage lingers. Within the past year, three separate major exploitable vulnerabilities in OpenSSL have been found, all in relation to the support for "export grade" keys. Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Languishing GPSD Update
On Mon, 22 Feb 2016, Mojca Miklavec wrote:
> On 22 February 2016 at 01:56, Fred Wright wrote:
> > On Wed, 10 Feb 2016, Fred Wright wrote:
> >> On Sat, 6 Feb 2016, Fred Wright wrote:
> >>
> >> > It's been 3 weeks since I posted patches to update gpsd to 3.16 (ticket
> >> > #50288), fixing #47739 in the process.
> >
> > Now 5 weeks. Although this got some attention, it's still in limbo.
>
> I would love to see the port upgraded as well, but given that it's a
> maintained port I still hope that its maintainer will respond and do
> the commit. (I don't dare to touch it unless Ryan asks for help.)
Actually, Ryan already mentioned that he tried to update it once, but
ran afoul of the dbus linking error, which is one of the many things I
fixed.
It is, after all, listed as "openmaintainer".
> The line "#!/usr/bin/env python" in "/opt/local/bin/xgps" for example
> is something that should also be fixed.
>
> On my machine I get:
>
> > xgps
> File "/opt/local/bin/xgps", line 644
> Base.gpsfields = map(lambda ((label, hook), widget): (hook, widget),
> ^
> SyntaxError: invalid syntax
>
> (Because I use "port select python python3.5" and I don't want to
> change that for a number of reasons. But I never used xgps so far, so
> I never noticed it.)
Actually, that specific problem is fixed by the switch to 'python2' in the
shebang lines in 3.16, but then you need to have a 'python2'.
Using a problem which is *fixed* (to some extent, anyway) by a proposed
patch as reason not to accept the patch is rather disingenuous. :-)
> Btw, the port misses some other dependencies like py27-pygtk:
>
> > python2.7 /opt/local/bin/xgps
> Traceback (most recent call last):
> File "/opt/local/bin/xgps", line 26, in
> import gtk
> ImportError: No module named gtk
Again, that's something I already fixed (as mentioned in the ticket).
> Replacing the shebang with "#!${prefix}/bin/python2.7" doesn't really
> reduce maintainability of the port. The divergence from upstream is
> necessary in this case to make sure that the port works for everyone.
It reduces maintainability by requiring the port to know what files need
to be patched. And you can't use wildcards because the files in question
don't have .py extensions.
Although I'm coming around to seeing the versioned shebang lines as a
necessary evil (which could actually be made unnecssary, but it would be
quite a bit of work), I think this should be handled (optionally) by
GPSD's own build script. I'm working on convincing Eric that this is a
useful feature.
*But*, nobody complained about the generic shebang lines in any of the
previous 47 versions of this port. And probably the only reason anyone
noticed this time is that I included the warnings for people that don't
have a 'python2' command established (which I notice is now being
suggested by the port notes for Python).
Aside from getting it off my plate, I have no personal need to get this
patch accepted at all, since:
1) My private copy of the port works just fine.
2) The upstream GPSD from HEAD now builds just fine on OSX "out of the
box"
3) Because of the development and testing I'm doing on the upstream GPSD,
I need to have the MacPorts version not installed most of the time,
anyway.
So the only reason for me to push this patch is for others. If nobody
wants a newer version enough to *maybe* need a 'python2' command to run
some of the programs without an explicit Python invocation, then so be it.
BTW, the upstream GPSD is approaching full Python 3 compatibility, but in
order to test with as many versions as I wanted, I not only needed to
expand the Python version lists of several ports, but also had to make
tweaked versions for 4 out of the 6 relevant Python ports in order to
undisable select.poll.
Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Languishing GPSD Update
On Wed, 10 Feb 2016, Fred Wright wrote: > On Sat, 6 Feb 2016, Fred Wright wrote: > > > It's been 3 weeks since I posted patches to update gpsd to 3.16 (ticket > > #50288), fixing #47739 in the process. Now 5 weeks. Although this got some attention, it's still in limbo. General summary: GPSD is primarily a C package, which also happens to include some Python programs. These are actually optional in the upstream version, though the MacPorts port doesn't include a corresponding variant. Since GPSD requires scons to build, it would need Python as a build dependency anyway, so there isn't much value in a no-Python variant. Thus, all users get the Python programs, whether or not they actually plan to use them (with the exception of two that I made optional in this version due to their heavyweight dependencies). The Python code in GPSD is compatible with 2.6 and 2.7, and even with 2.4 and 2.5 if "simplejson" is available, though the dependency is currently set up for just python27, only because there's no way to allow for multiple Python versions without either using variants or using the monoversioned subport approach. Either approach is additional work that doesn't really gain much in practice, given that the scons port is currently dependent specifically on python27 (probably for similar reasons, since scons itself is compatible with Python2 >=2.4). And the monoversioned subport approach (as currently implemented) doesn't even work for ports that aren't pure Python, since it winds up trying to install C programs and C libraries in Python-version-specific directories. Up through version 3.15 (the latest published MacPorts version is 3.14), the GPSD Python programs just used the generic '#!/usr/bin/env python' as the shebang line. They don't actually work with Python3, but in general, making Python3 the default is likely to cause lots of problems, so that hasn't been much of an issue in practice. However, apparently at least one Linux distro has made Python3 the default, so the 3.16 release of GPSD changed all the shebang lines to specify 'python2'. This is exactly the right thing for any PEP0394-compliant system, where 'python2' is guaranteed to be some Python2.x, but doesn't necessarily work on OSX. The only real difference between 'python' and 'python2' on OSX is that Apple provides the former but not the latter. I.e., there's always a 'python' command on OSX (regardless of what one does with python_select), but not necessarily a 'python2' command. Since some users may not have set up a 'python2' command (via python2_select or otherwise), I thought it useful to include a warning in the form of a "port note" in that case. I also included an explicit dependency on python2_select (nominally redundant given the dependency from python27) since I think it's bad practice to rely on indirect dependencies for direct requirements. The latter part first led to a small pushback on the python2_select depndency (which I think I adequately answered), but then some more with one poster's preference for adding additional patches to inflict unnecessary monoversionism on the Python programs. The latter not only reduces maintainability by increasing the divergence from upstream, but also represents a philosophical departure from former versions of the port, solely to avoid encouraging users to make their setups PEP0394-compliant. I don't think that encouraging the use of python2_select is a bad idea in general, given that more Python3-incompatible programs are likely to be switching to specifying 'python2' as more OS distros switch to Python3 as the default (though that's not likely for OSX itself anytime soon). In fact, it might make sense to add that recommendation to the notes for the Python2.x ports (expanding the existing notes about python_select). Meanwhile, MacPorts hasn't had an up-to-date port of GPSD in almost nine months. Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Languishing GPSD Update
Resending after subscribing. On Sat, 6 Feb 2016, Fred Wright wrote: > It's been 3 weeks since I posted patches to update gpsd to 3.16 (ticket > #50288), fixing #47739 in the process. > > Also, the obsolete update request for 3.15 (#50237) should be closed. > > Fred Wright ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
