October 2015 - macports-tickets - lists.macosforge.org

[MacPorts] #48940: Request: Upgrad go from 1.4.2 to 1.5.1
by MacPorts 03 Oct '15

03 Oct '15

#48940: Request: Upgrad go from 1.4.2 to 1.5.1 -------------------------+-------------------------------- Reporter: lutz.horn@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: go -------------------------+-------------------------------- The [https://golang.org/ Go programming language] has been upgraded to [https://golang.org/doc/go1.5 version 1.5]. Mac Ports still contains version 1.4.2. Please update the [https://trac.macports.org/browser/trunk/dports/lang/go/Portfile go port] to the current version. -- Ticket URL: <https://trac.macports.org/ticket/48940> MacPorts <https://www.macports.org/> Ports system for OS X

1 8

[MacPorts] #49083: BUG: go isn't UsingTheRightCompiler
by MacPorts 03 Oct '15

03 Oct '15

#49083: BUG: go isn't UsingTheRightCompiler ------------------------+------------------------- Reporter: mcalhoun@… | Owner: ciserlohn@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: haspatch | Port: go ------------------------+------------------------- Since r140801, go isn't UsingTheRightCompiler.[[BR]] Attached is a proposed solution. -- Ticket URL: <https://trac.macports.org/ticket/49083> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #45470: botan: needs revision update for universal builds
by MacPorts 03 Oct '15

03 Oct '15

#45470: botan: needs revision update for universal builds ------------------------+------------------- Reporter: mcalhoun@… | Owner: mww@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.2 Keywords: | Port: botan ------------------------+------------------- The build.h file merges incorrectly in a universal build due to nested comments.[[BR]] This is similar to #25439.[[BR]] A fix similar to r79694 should fix the problem. -- Ticket URL: <https://trac.macports.org/ticket/45470> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

Re: [MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
by MacPorts 03 Oct '15

03 Oct '15

#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by rjvbertin@…): Thanks Bradley...! Replying to [comment:62 mojca@…]: > So if I understand properly, installing both ports (your new qt[45]-mac) as well as the transitional subport will make sure that all the ports that haven't been fixed and/or rebuilt yet will happily keep working? And the transitional subport will only be a problem when building other ports against qt5? If that is so, the transition might be a lot less painful than what I imagined. More or less. I never made a transitional variant or subport for qt5-mac because there were so many (and even fewer *big*) ports that depend on Qt5 and to be honest, because I had none installed. But yes, install my qt4-mac-devel + qt4-mac-devel-transitional, and all your existing Qt4 dependent ports will keep working, and port rev-upgrade won't see a single problem. That was a requirement for me to start working on a Qt4 port, so it's the first thing I made certain worked as it should. It's very simple really; the subport installs symlinks to everything in the new Qt frameworks directory into ${prefix}/Library/Frameworks (and "fake dylibs" into ${prefix}/lib) where those items were installed by the older exclusive port.[[BR]] Where you're wrong is that the transitional Qt4 subport is no problem for building other ports against Qt5. It's possible that even an equivalent Qt5 transitional subport would NOT clash with the Qt4 transitional port because Qt5's libraries and frameworks have different names Where things can go awry installing qt4-mac-devel and qt4-mac-devel- transitional is when `rev-upgrade` starts rebuilding between those 2 installs. That never happened to me, but I always installed them both in a single command, i.e. `port install qt4-mac-devel [+variant(s)] qt4-mac-devel-transitional` I've had some opportunity to double-check what I said earlier, and indeed: * deactivate qt4-mac-devel-transitional followed by a rev-upgrade to have a break-down of ports not rebuilt against the new concurrent Qt4 install. This also suggest that a rev-bump won't even be necessary. * reactivate qt4-mac-devel-transitional, and rebuild the listed ports one by one (e.g. with `port -ns upgrade --force foo` will make them depend on the new install layout I haven't had time to rebuild all Qt4 dependents that still require rebuilding, but I see no reason to assume that qt4-mac-devel-transitional will still be required afterwards. Except of course to remain compatible with binary packages of Qt4 ports I haven't installed yet. > Potentially the qt4-mac-devel could be called qt4? It could. Or qt4-devel, if we suppose that it has some kind of development nature. -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:65> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
by MacPorts 03 Oct '15

03 Oct '15

#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by pixilla@…): Replying to [comment:63 rjvbertin@…]: > Replying to [comment:62 mojca@…]: > > Replying to [comment:60 rjvbertin@…]: > > > First off, existing users can be warned not to upgrade to 10.11, but I guess you also have newcomers in mind (who'd have to be told to wait until compatibility issues are fixed). > The vast majority of the ones I've installed simply rebuild because 1) they use the Qt4 portgroup and 2) my layout changes are so minimal. > > > Btw: if we are moving the complete structure anyway, what about renaming the new port simply to `qt4`? Now that x11 is hardly support (and probably not needed), there is no way to keep calling that port `"mac"`. That way we could keep the old `qt4-mac` in place for a while (and ports that won't be upgraded yet might conditionally keep working), while urging everyone to switch to the new `qt4` asap and update the ports to use qt4 instead of qt4-mac? I think it would be less confusing for the "standard" qt{4,5} ports to be named qt4 and at5 and let "specialty" ports add a suffix. > Which still boils down to the same thing, at least if I understand correctly that those ports do not yet have (published) Qt5 variants/subports. > > > May I perhaps suggest you to put your files to a place like GitHub or any other public service, so that it becomes slightly easier to track your changes for those who might be interested? Uploading zips to trac starts getting cumbersome at some point, particularly with the amount of changes that you need to make. > > Has been the case for months: https://github.com/RJVB/macstrop/tree/master/aqua ... I hope the substantial time and effort René has put into making QT and KDE better on the Mac can finally make it's way into MacPorts in whole, pieces or spirit. A quick look at the relevant KDE mail lists and issue trackers will show an impressive tail of contributions. -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:64> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #49075: go, go-1.4: can't read "GOARCH": no such variable
by MacPorts 03 Oct '15

03 Oct '15

#49075: go, go-1.4: can't read "GOARCH": no such variable --------------------------+------------------------- Reporter: ryandesign@… | Owner: ciserlohn@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: powerpc | Port: go, go-1.4 --------------------------+------------------------- go and go-1.4 fail to parse on PowerPC systems: {{{ can't read "GOARCH": no such variable }}} This is because you removed {{{ default { # unsupported arch, but GOARCH needs to be set to something to prevent errors set GOARCH x set cmd_prefix 6 } }}} from the `switch ${build_arch}` statement in r140801. It's fine if a port doesn't install on PowerPC, but please at least don't cause the port to fail to parse, because users see that error when selfupdating or syncing, and because it prevents valid commands like "sudo port clean all" from completing. -- Ticket URL: <https://trac.macports.org/ticket/49075> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #48909: Updating the documentation and guide to make clear that port upgrade outdated is the recommended method.
by MacPorts 03 Oct '15

03 Oct '15

#48909: Updating the documentation and guide to make clear that port upgrade outdated is the recommended method. -------------------------+-------------------------------- Reporter: aszostak@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: contrib | Version: 2.3.99 Keywords: | Port: -------------------------+-------------------------------- Currently the documentation in the manpages and guide give a false impression to inexperienced users that upgrading a single port is always a safe operation. After a discussion on the mailing list it has become apparent that this is not the case. The only really safe and recommended upgrade method is "port upgrade outdated" and should be used by most users. The attached patch contains suggested modifications to the documentation code base that would make this explicit to inexperienced users reading the manpage or online guide. -- Ticket URL: <https://trac.macports.org/ticket/48909> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #48524: qt5-mac upgrade to 5.5.0
by MacPorts 03 Oct '15

03 Oct '15

#48524: qt5-mac upgrade to 5.5.0 ----------------------+-------------------------------- Reporter: eirnym@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: qt5-mac ----------------------+-------------------------------- QT5 upgraded to 5.5. -- Ticket URL: <https://trac.macports.org/ticket/48524> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

Re: [MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
by MacPorts 03 Oct '15

03 Oct '15

#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by rjvbertin@…): Replying to [comment:62 mojca@…]: > Replying to [comment:60 rjvbertin@…]: > > First off, existing users can be warned not to upgrade to 10.11, but I guess you also have newcomers in mind (who'd have to be told to wait until compatibility issues are fixed). > >I would expect that a lot of other ports would have to be fixed to continue working with the new Qt4 structure. The vast majority of the ones I've installed simply rebuild because 1) they use the Qt4 portgroup and 2) my layout changes are so minimal. > Btw: if we are moving the complete structure anyway, what about renaming the new port simply to `qt4`? Now that x11 is hardly support (and probably not needed), there is no way to keep calling that port `"mac"`. That way we could keep the old `qt4-mac` in place for a while (and ports that won't be upgraded yet might conditionally keep working), while urging everyone to switch to the new `qt4` asap and update the ports to use qt4 instead of qt4-mac? Something I proposed for the Qt5 port and that got no traction at all. Besides, if ever we do end up with qt*-kde ports there'd actually be a reason for the -mac suffix ... > Which is even worse. Because then I have no option to link, say, gnuplot against qt5-kde if I happen to like the kde structure more. Becasue that will make gnuplot conflict with just about every other Qt-based package in MacPorts. No. I've taken care that installing qt5-kde does not get you into conflict with binary packages built against qt5-mac. The other way around is less sure, but can be protected the same way. If you prefer the kde structure, you'll just end up using that structure for all Qt dependents, and I think it'll be possible to get binary packages for at least some of those (the ones conceived to be used with the kde structure in any case). > I maintain a bunch of Qt-based ports that all work with Qt5, but I cannot afford to keep and test compatibility against Qt5 or get rid of Qt4 completely as long as qt5-mac is conflicting with qt4-mac. Which still boils down to the same thing, at least if I understand correctly that those ports do not yet have (published) Qt5 variants/subports. > May I perhaps suggest you to put your files to a place like GitHub or any other public service, so that it becomes slightly easier to track your changes for those who might be interested? Uploading zips to trac starts getting cumbersome at some point, particularly with the amount of changes that you need to make. Has been the case for months: https://github.com/RJVB/macstrop/tree/master/aqua ... > > > About the install layout/directory structure: I've seen it argued that just putting everything into a single directory is how Digia do it with their own installers, on OS X. True, but the use case they envision is developers who build standalone app bundles that can be submitted to the App Store. That's not the reason for which MacPorts contains Qt, I think. There are Qt ports so there can be any number of other ports to depend on the appropriate Qt version. Most of those dependents probably come from other Unix desktops where Qt does not install in a single directory. > > Quick question: do I understand it properly that some of your ports (mostly those based on KDE) do not even work if one installs the complete Qt into a single directory like libexec? If that is the case, we might have a strong argument to try to keep the directories spread out at their usual location. > Or do both configurations (either a single directory or different directories) work with most ports? I do not have time to answer that in detail right now. The quick answer is that I initially used an all-encompassing prefix for Qt4 too when I set out to make qt4-mac concurrent. I remember running into issues, didn't record exactly what, but in retrospect those issues were evidently related to the prefix approach. Basically I consider that MacPorts contains many ports that were conceived for a Freedesktop/XDG environment (including all KDE4 ports), and that as a result we'd do better to stick to something as close to that kind of layout as possible. Which was the case for the "exclusive" qt4-mac layout. Gotta run... -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:63> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #47806: OpenCoarrays @1.0
by MacPorts 03 Oct '15

03 Oct '15

#47806: OpenCoarrays @1.0 ------------------------------+-------------------------------- Reporter: fanfarillo.gcc@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: ------------------------------+-------------------------------- Open-source software project for developing, porting and tuning transport layers that support coarray Fortran compilers. The version provided is based on MPI-3.0 (requires mpich) and it is currently used by GNU Fortran (GCC 5). -- Ticket URL: <https://trac.macports.org/ticket/47806> MacPorts <https://www.macports.org/> Ports system for OS X

1 43