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

[MacPorts] #49086: Bad user experience if user forgets to save a list of requested ports before OS upgrade
by MacPorts 05 Oct '15

05 Oct '15

#49086: Bad user experience if user forgets to save a list of requested ports before OS upgrade -------------------------+-------------------------------- Reporter: macports@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: -------------------------+-------------------------------- I recently upgraded my Mac to El Capitan. Before upgrading, I forgot that MacPorts requires a new, clean install for each upgrade and therefore I did not save a list of my requested ports. After the upgrade, all my ports appear to work fine but the `port` command itself refuses to run, asking me to read the article on Migration. I have read it, but item 3 of the procedure asks one to run the port command to save a list of installed/requested ports. The main problem is that this step should be run BEFORE the upgrade, not AFTER. If the user forgets to save the list, MacPorts will even refuse to print the list after the upgrade. This can be worked around by deleting line 617 of libexec/macports/lib/macports1.0/macports.tcl but I doubt many users would go that far. At least making this modification will cause MacPorts to run so that the user may print out a list of installed/requested ports. -- Ticket URL: <https://trac.macports.org/ticket/49086> MacPorts <https://www.macports.org/> Ports system for OS X

1 6

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

05 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@…): * It's very likely that KF5 will require a Qt5 install with specific patches that we may not want to impose on everyone. Ports cannot depend on a variant, so in that case a dedicated port will be required. I agree that's a much stronger argument for a dedicated port than simply the install layout. * There is no question of maintaining 2 variants of all dependents. Proper configuration of the PortGroup will ensure that ports that do not have a hard requirement on the one or the other (and thus a conflict with the other or the one) will build with all Qt ports. There could be 1 or 2 corresponding variants that act as a protection against installing the wrong binary build, but that's handled purely in the PortGroup, and maintained by the qt*-kde maintainer (which I reckon would be me). I've been very clear I think that there is absolutely no reason to change more to the current install layout than strictly necessary, and good reasons to *not* to do that ''*)''. It seems Mojca agrees with me; maybe we should invite opinions from more "core" MacPorts developers who are maybe more likely to provide additional arguments based on MacPorts guidelines. ("Follow Linux/Freedesktop/XDG conventions" , "avoid duplicating directory structures", etc.) I'm compelled to come back one last time to my suggestion to commit my qt4 -mac-devel (which wouldn't even "destroy" the existing qt4-mac-devel; that one was very obsolete last time I looked). Mojca voiced concerns about repeated and expensive rebuild cycles, and I understand that we're now facing pressure to "get through with it already" because of 10.11's imminent release. I cannot really imagine that there will be many early updaters who are on old hardware where building Qt is an issue. Providing an up-to-date qt4 -mac-devel will give the other early updaters a working solution that may even be replaced by a drop-in replacement qt4-mac port in the end. And that wouldn't exclude applying the 10.11 patch to the current port (without even rev-bumping it; not required for users who do not already have an installed version). ''*) I do realise that I should have kept a record of the issues I identified while experimenting with an all-encompassing install prefix myself.'' -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:73> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #49095: postgresql94 El Capitan initdb using default instructions fails without any failure message.
by MacPorts 05 Oct '15

05 Oct '15

#49095: postgresql94 El Capitan initdb using default instructions fails without any failure message. ---------------------+-------------------------------- Reporter: neilt@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: postgresql94 ---------------------+-------------------------------- Removed MacPorts and Xcode, upgraded to El Capitan, install Xcode 7.0.1, install new MacPorts 2.3.4. Then start installing ports manually. Installed postgresql94 then postgresql94-server. Created the default dir using the commands from the install script. Then I went to look at the init'd database and it was not present. {{{ MBP:postgresql94 nt$ sudo mkdir -p /opt/local/var/db/postgresql94/defaultdb MBP:postgresql94 nt$ sudo chown postgres:postgres /opt/local/var/db/postgresql94/defaultdb MBP:postgresql94 nt$ sudo su postgres -c '/opt/local/lib/postgresql94/bin/initdb -D /opt/local/var/db/postgresql94/defaultdb' MBP:postgresql94 nt$ cd /opt/local/var/db/postgresql94/defaultdb MBP:defaultdb nt$ pwd /opt/local/var/db/postgresql94/defaultdb MBP:defaultdb nt$ ls -lah total 0 drwxr-xr-x 2 postgres postgres 68B Oct 4 12:47 . drwxr-xr-x 3 root admin 102B Oct 4 12:47 .. MBP:defaultdb nt$ cd .. MBP:postgresql94 nt$ pwd /opt/local/var/db/postgresql94 MBP:postgresql94 nt$ ls -lah total 0 drwxr-xr-x 3 root admin 102B Oct 4 12:47 . drwxr-xr-x 3 root admin 102B Oct 4 12:47 .. drwxr-xr-x 2 postgres postgres 68B Oct 4 12:47 defaultdb }}} The above is the exact output from the commands. The port install did not show any abnormal results at all. I did the 'csrutil disable' thinking that might be part of the problem with the new security, but it did not make a difference. I have removed postgresql and installed it multiple times. The binaries are present '/opt/local/lib/postgresql94/bin' If I try to initdb a database in my user account it works fine. {{{ MBP:~ nt$ mkdir postgresql_test MBP:~ nt$ cd postgresql_test MBP:postgresql_test nt$ /opt/local/lib/postgresql94/bin/initdb -D . The files belonging to this database system will be owned by user "nt". This user must also own the server process. The database cluster will be initialized with locale "C". The default database encoding has accordingly been set to "SQL_ASCII". The default text search configuration will be set to "english". Data page checksums are disabled. fixing permissions on existing directory . ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 128MB selecting dynamic shared memory implementation ... posix creating configuration files ... ok creating template1 database in ./base/1 ... ok initializing pg_authid ... ok initializing dependencies ... ok creating system views ... ok loading system objects' descriptions ... ok creating collations ... ok creating conversions ... ok creating dictionaries ... ok setting privileges on built-in objects ... ok creating information schema ... ok loading PL/pgSQL server-side language ... ok vacuuming database template1 ... ok copying template1 to template0 ... ok copying template1 to postgres ... ok syncing data to disk ... ok WARNING: enabling "trust" authentication for local connections You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb. Success. You can now start the database server using: /opt/local/lib/postgresql94/bin/postgres -D . or /opt/local/lib/postgresql94/bin/pg_ctl -D . -l logfile start MBP:postgresql_test nt$ }}} I don't have any idea how to troubleshoot this when no error messages are printed. -- Ticket URL: <https://trac.macports.org/ticket/49095> MacPorts <https://www.macports.org/> Ports system for OS X

1 5

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

05 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 mojca@…): Two points: * Breaking the Qt might be unavoidable, but I would prefer if that would be done '''just once''' rather than committing some minimal subset now and then doing another incompatible commit (requiring a revbump of all dependents) with all the desired fixes again one month from now. * If we would have to support two or more flavours of Qt (for example qt5-mac and qt5-kde) and two variants of all the dependent ports just because qt{4|5}-mac is not configured properly to support KDE applications, that is a very stupid reason to ship two incompatible ports and a great recipe to introduce more confusion. Please let's make sure that qt{4|5} works for everyone (including KDE), so that there won't be any need for "workaround ports". -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:72> 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 05 Oct '15

05 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:68 michaelld@…]: > * When we get QtChooser and/or qt*-kde implemented, we'll need some of these in place; until then, I think we can leave them alone. "These" being what, here? > * Moving sqlite3 back to the main qt4-mac makes sense too, because otherwise Assistant fails to execute; either that or moving Assistant to a separate port that depends on the sqlite3 plugin; much easier to do the former. Indeed; much easier, and a *lot* faster. > * I don't know enough about "-no-exceptions" to comment. Can you provide a link that shows that this is the default for Qt-provided binaries? I'm happy to go that way with a variant if it's the usual. At least on Qt4, when I do "./configure --help" I see that "-exceptions" is the default; that's why it is enabled by default. No, I never said it's the default for Qt-provided binaries. With the change I propose Qt4 builds as Qt5 does, without using exceptions internally (except for a few ... exceptions like QtConcurrent) and without support for exceptions enabled in the compiler. That is in fact what we're talking about. As I said in my previous comment, Qt's configure `-no- exceptions` has effect also on how dependent software is built, but my implementation removes that. With some luck I'll be able to trace the exchange with Thiago in the archives of the interest Qt ML, but that's going to be the only link I can provide. I myself used a variant (first optional, then default) before finally realising that everything just works, and making the `-exceptions` build under control of a variant. > * No matter the proper way to do a parallel build, MP's way works, yes? If so, I'll leave that as is. What do you call the MP way, by setting build.jobs? That does NOT work, which is the reason for setting MAKEFLAGS. If you look at the `configure` script, qmake is built by invoking `make` without any options at all. I initially patched the configure script, but after asking on the interest ML I was told that "you just have to use `MAKEFLAGS=-jn` ... > * I think setting "qt_name qt4" is fine. Reads nicely in directory listings too. That's what I use for my internal testing, too. Yes, much as I think that we should simply maintain the qt4-mac port name, I would hate to see that in the directory structure. Too big, and there is an additional argument against it in the case of Qt5 which I won't repeat here ;) > * my worry about moving data, plugins, and other stuff into ${prefix}/share/qt4 is if/when there is qt4-kde or qt4-x11 that provides its own versions of these. No, I don't think so. I'm not 100% certain about the plugins of a qt4-x11 build, but qt4-kde will install the exact same things in the shared resource directories as qt4-mac does. > A well-written project will use the specified QMAKE to glean the location of these, so they really don't matter. The issues I had were not with building. They were runtime issues that IIRC would have required patching the affected dependent ports. Of course, if you have no objections against a qt4-kde port then all we need to agree upon is how to set up the PortGroup(s) so that users can decide to install either the qt4-mac or qt4-kde flavour (but not both, IMHO) and at most be obliged to support installing from source those ports that do not specifically request the installed Qt4 flavour. You may have seen that I have a draft implementation for Qt5 (converting the Qt5 PortGroup into a "header" that loads either the Qt5-mac or the Qt5-kde PortGroup). -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:71> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #36727: gdb 7.5 BFD unknown load command & Unable to find Mach task port
by MacPorts 05 Oct '15

05 Oct '15

#36727: gdb 7.5 BFD unknown load command & Unable to find Mach task port -------------------------+------------------------------- Reporter: jb_duffy@… | Owner: stuartwesterman@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: gdb | -------------------------+------------------------------- Changes (by peter.linss@…): * status: closed => reopened * resolution: fixed => Comment: Having the same issue with El Capitan and GDB @7.9.1_3+python34 (MacPorts 2.3.4). I have turned off System Integrity Protection and added the 'p' argument to taskgated as above (and rebooted) and still get: Unable to find Mach task port for process-id 537: (os/kern) failure (0x5). (please check gdb is codesigned - see taskgated(8)) -- Ticket URL: <https://trac.macports.org/ticket/36727#comment:22> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #49105: py26-mustache install fails with checksum error on El Capitan
by MacPorts 05 Oct '15

05 Oct '15

#49105: py26-mustache install fails with checksum error on El Capitan -----------------------+-------------------------------- Reporter: rlhamil@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: elcapitan | Port: -----------------------+-------------------------------- Error: org.macports.checksum for port py26-mustache returned: Unable to verify file checksums -- Ticket URL: <https://trac.macports.org/ticket/49105> 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 05 Oct '15

05 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:69 hans_meine@…]: > AFAIK, -no-exceptions ''was'' the default (maybe only de-facto) in the past, in the era of GCC 2.95 and 3.x, when it would seriously speed up large Qt-based projects (e.g. KDE). However, compilers have become more efficient in the meantime, and more people are actually ''making use'' of exceptions (e.g. in the past, their use was discouraged in KDE for performance reasons), so the recommendation was changed. I have started implementing this approach after "Qt's own" Thiago Macieira affirmed me that it didn't change anything, and that Qt itself doesn't do anything with exceptions internally except in a few modules. Since those are an integral part of QtCore, all of QtCore is built with exceptions enabled in my approach. I considered going for a finer resolution, but decided that would be overdoing it. My change does take care that the `no- exceptions` setting does NOT propagate to dependents. The standard way of building Qt4 with `-no-exceptions` does indeed do that for some reason, but those changes can be reverted (see the post-destroot extract above) and applications using Qt can continue to use exceptions. You can imagine how I discovered that post-destroot bit was required, so yes, I have tested Qt dependent code that uses exceptions. -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:70> 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 05 Oct '15

05 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 hans_meine@…): AFAIK, -no-exceptions ''was'' the default (maybe only de-facto) in the past, in the era of GCC 2.95 and 3.x, when it would seriously speed up large Qt-based projects (e.g. KDE). However, compilers have become more efficient in the meantime, and more people are actually ''making use'' of exceptions (e.g. in the past, their use was discouraged in KDE for performance reasons), so the recommendation was changed. (With -no-exceptions, you would have to catch exceptions before entering Qt; I do not want to imply that it is not possible at all to use exceptions with -no-exceptions.) -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:69> 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 05 Oct '15

05 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 michaelld@…): There are some good suggestions in your last comment, René. * When we get QtChooser and/or qt*-kde implemented, we'll need some of these in place; until then, I think we can leave them alone. * Moving sqlite3 back to the main qt4-mac makes sense too, because otherwise Assistant fails to execute; either that or moving Assistant to a separate port that depends on the sqlite3 plugin; much easier to do the former. * I don't know enough about "-no-exceptions" to comment. Can you provide a link that shows that this is the default for Qt-provided binaries? I'm happy to go that way with a variant if it's the usual. At least on Qt4, when I do "./configure --help" I see that "-exceptions" is the default; that's why it is enabled by default. * No matter the proper way to do a parallel build, MP's way works, yes? If so, I'll leave that as is. * I think setting "qt_name qt4" is fine. Reads nicely in directory listings too. That's what I use for my internal testing, too. * my worry about moving data, plugins, and other stuff into ${prefix}/share/qt4 is if/when there is qt4-kde or qt4-x11 that provides its own versions of these. A well-written project will use the specified QMAKE to glean the location of these, so they really don't matter. Hence, I'm inclined to leave them inside the libexec/qt4 area. I'll look over this list one last time tonight & also review any other comments. Might be tomorrow for the actual checkin, but I'll try for tonight. -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:68> MacPorts <https://www.macports.org/> Ports system for OS X

1 0