Re: How reconcile openmodelica-dvel & octave dependencies on sundials vs. sundials2

[Adam Dershowitz]

It took me a while to actually try this.  But, it does seem to work fine.  I 
would encourage someone to push this change to the port file.

Thanks for creating this diff.

--Adam



> On Jun 6, 2018, at 1:20 AM, Ken Cunningham  
> wrote:
> 
> Adam, Murray -- This small patch will patch the octave Portfile to make 
> sundials2 support a variant.
> If you want to install octave without sundials2 support (so you can use 
> openmodelica which needs sundials) this should allow you to do that.
> 
> The command is:
> 
> sudo port -v install octave -sundials2
> 
> I built octave locally without sundials2 support and it seems to build 
> cleanly.
> 
> I don't know how many people might want to install both octave and 
> openmodelica.
> If there are enough people, perhaps Marcus /Marius might add something like 
> this into the octave Portfile.
> 
> Best,
> 
> Ken
> 
> --- patch below ---
> 
> --- Portfile  2018-06-02 16:18:27.0 -0700
> +++ Portfile  2018-06-05 22:14:12.0 -0700
> @@ -295,6 +295,11 @@
> --without-magick\
> --disable-docs
> 
> +#default to no sundials support - see variant below
> +configure.args-append   \
> +--without-sundials_nvecserial \
> +--without-sundials_ida
> +
> # in configure.ac, listed as one of "[p]rograms used when running Octave"
> depends_lib-append port:python27
> configure.python ${prefix}/bin/python2.7
> @@ -365,10 +370,6 @@
> configure.args-append --without-openssl
> #depends_lib-append path:lib/libssl.dylib:openssl
> 
> -#--without-sundials_nvecserial
> -#--without-sundials_ida
> -depends_lib-append  port:sundials2
> -
> # see etc/README.MacOS
> depends_run-append   \
> port:epstool \
> @@ -399,6 +400,13 @@
> #https://trac.macports.org/ticket/51480
> #default_variants-append +java
> 
> +variant sundials2 description {build with sundials2 support - not compatible 
> with sundials} {
> +depends_lib-append  port:sundials2
> +configure.args-delete --without-sundials_nvecserial
> +configure.args-delete --without-sundials_ida
> +}
> +default_variants-append +sundials2
> +
> variant qt4 conflicts qt5 description {build the GUI using Qt4} {
> PortGroup qt4 1.0
> depends_lib-append port:qscintilla-qt4
> 

Re: Odd mpv configure series failure following fresh reinstall

[Lee Bast]

On Jun 20, 2018, at 1009 , Rainer Müller  wrote:On 2018-06-20 03:19, Lee Bast wrote:	Just wanted to give a small follow up: in the end I think the mpv port is just entirely broken for me. I kept trying things until I ended up doing a total fresh install again following updating to Xcode 9.4. Starting entirely from scratch and just doing a plain "port install mpv" with no variants or anything else installed first I still get the exact same error where configure fails on:info:configure Checking for Lua  : no ('lua-5.2 >= 5.2.0' not found) Just checking, is the lua52 port installed and active?	No, I did a total clean install blowing away everything (following https://guide.macports.org/#installing.macports.uninstalling) then tried 'port install mpv' as the very first port following self-update. lua52 is a dependency of mpv, so like any other port it's installed first along with all other not present dependencies before it finally gets to mpv right? In my first encounter (back on June 7th) of the problem if I manually installed lua then that check would pass, except that then it would immediately fail on the next dependency, and so on. I can't think of any other port where there is a need to manually install every single dependency unless the user wants a custom variant or to try to force the use of something non-default (like libressl vs openssl). I don't think lua specifically is the issue here, rather it's something in how the port is handling dependency installation, or some other interaction.The problem can probably only be debugged further by looking intoconfig.log, which contains the details how and where mpv expected tofind Lua. Use this command to find this file after the failed build attempt:$ find $(port work mpv) -name config.log	Here you go:

mpv-config.log
Description: Binary data
At the end it says "err: Package file '/opt/local/lib/pkgconfig/lua-5.2.pc' appears to be empty", and navigating to there yeah it's 0. It actually looks like every dependency of the mpv port install is size 0:% gls -l --si -S[...]-rw-r--r-- 1 root     admin    0 Jan 20 09:44 dvdnav.pc-rw-r--r-- 1 root     admin    0 Jan 20 09:46 dvdread.pc-rw-r--r-- 1 root     admin    0 Sep 30  2017 libcddb.pc-rw-r--r-- 1 root     admin    0 Sep 30  2017 libcdio++.pc-rw-r--r-- 1 root     admin    0 Sep 30  2017 libcdio.pc-rw-r--r-- 1 root     admin    0 Sep 30  2017 libcdio_cdda.pc-rw-r--r-- 1 root     admin    0 Sep 30  2017 libcdio_paranoia.pc-rw-r--r-- 1 root     admin    0 Apr  5 20:14 libdvdcss.pc-rw-r--r-- 1 root     admin    0 Sep 30  2017 libiso9660++.pc-rw-r--r-- 1 root     admin    0 Sep 30  2017 libiso9660.pc-rw-r--r-- 1 root     admin    0 Sep 30  2017 libudf.pc-rw-r--r-- 1 root     admin    0 Sep 30  2017 lua-5.2.pc-rw-r--r-- 1 root     admin    0 May 26 13:41 rubberband.pc-rw-r--r-- 1 root     admin    0 Jun  2 11:08 sndfile.pcAt this point I've already reinstalled all my other regular ports so this list is a lot shorter then it'd be on a fresh install I assume, ffmpeg & mkvtoolnix etc already covered much of what mpv would want. Only the remaining dependencies exclusively left to mpv show size zero. I don't know what to make of that. I assume all sizes for a port installing dependencies being zero is not normal? Also, to make another guess on what is going on, what is the result ofthe following command on your system?$ pkg-config --libs --cflags lua-5.2-I/opt/local/include/lua-5.2 -L/opt/local/lib/lua-5.2 -llua-5.2 -lm"Unknown option -I"Thanks for your suggestions of something else to look at! I didn't think to look at that build config.log before vs the main log.Lee

Re: gnucash not finding dbus

[Joshua Root]

Lenore Horner wrote:
>> On Jun 20, 2018, at 04:26, Ryan Schmidt  wrote:
>> 
>> 
>> On Jun 19, 2018, at 21:05, Lenore Horner wrote:
>> 
>>> On Jun 11, 2018, at 17:57, Lenore Horner wrote:
>>> 
 gnucash is saying
 Dynamic session lookup supported but failed: launchd did not provide a 
 socket path, verify that org.freedesktop.dbus-session.plist is loaded!
 
 but when I try to start dbus—session I get
 /opt/local/Library/LaunchAgents/org.freedesktop.dbus-session.plist: 
 service already loaded
 
 so why isn’t gnucash seeing it?  
>>> 
>>> No one else is seeing this behavior and no one has any clue how to fix it?
>> 
>> Does unloading and then loading that plist help?
>> 
> I tried that and now the plist can’t even be found.  I ended up uninstalling 
> dbus and reinstalling and then loading (w/o sudo as currently advised).  I 
> notice that we used to be told that dbus had created start-up items but they 
> were not enabled by default.  Now we’re told start-up items were not created. 
>  Does that mean I’ll have to re-issued the load commands for dbus every time 
> I restart my computer now?

Do you have startupitem_install set to 'no' in your macports.conf? That
will prevent symlinks to the plists being placed in
/Library/LaunchAgents or /Library/LaunchDaemons, and would be consistent
with your plist being loaded from /opt/local/Library/LaunchAgents. I'm
not sure how well things will persist across logouts and reboots with
that arrangement, but a user asked for it to be allowed, so it is as of 2.5.

'port notes dbus' says this for me:
dbus has the following notes:
  Startup items (named 'dbus-system, dbus-session') have been generated that
  will aid in starting dbus with launchd. They are disabled by default.
Execute
  the following command to start them, and to cause them to launch at
startup:

  sudo port load dbus

Running 'port load dbus' without sudo will skip loading dbus-system,
because it requires root privileges, but will load dbus-session for the
current user.

Running 'sudo port load dbus' will load dbus-system and will also load
dbus-session for the current user (determined from the $SUDO_USER
environment variable set by sudo).

If dbus is showing different notes for you, it's because your
configuration is different in some way.

- Josh

Re: Preventing check of sharedlibs in rev-upgrade

[Joshua Root]

The basic test is that the files referred to by each mach-o file's load
commands exist. It uses pretty much the same information that is shown
by 'otool -L /path/to/file'.

If you run rev-upgrade with the -v (or -d) option, it will show the
specifics of why it considers files to be broken.

- Josh

On 2018-6-21 02:01 , Artur Szostak wrote:
> Is the algorithm for the rev-upgrade stage documented anywhere so I can 
> understand exactly how it is trying to identify that a shared library is 
> broken?
> 
> 
> From: Joshua Root 
> Sent: 20 June 2018 13:34
> To: Artur Szostak
> Cc: MacPorts Users
> Subject: Re: Preventing check of sharedlibs in rev-upgrade
> 
> Artur Szostak wrote:
>> Is there any way of telling MacPorts to not consider one, more or all shared 
>> libraries when attempting its check for broken libraries in a Portfile? I 
>> have some Java software which is precompiled and also delivering some 
>> additional shared libraries. Unfortunately, MacPorts is incorrectly 
>> detecting some of the shared libraries as broken and attempting to recompile 
>> the package.
> 
> You can't disable it on a per-port basis, but you can prevent
> rev-upgrade from running automatically, or put it in report-only mode,
> with settings in macports.conf.
> 
> If it is indeed incorrectly considering some files broken, that is a bug
> that we should fix, so please file a ticket. (Have you checked that the
> detected brokenness could not be fixed with install_name_tool like e.g.
> oracle-instantclient does?)
> 
> - Josh
> 

Re: Preventing check of sharedlibs in rev-upgrade

[Artur Szostak]

Is the algorithm for the rev-upgrade stage documented anywhere so I can 
understand exactly how it is trying to identify that a shared library is broken?


From: Joshua Root 
Sent: 20 June 2018 13:34
To: Artur Szostak
Cc: MacPorts Users
Subject: Re: Preventing check of sharedlibs in rev-upgrade

Artur Szostak wrote:
> Is there any way of telling MacPorts to not consider one, more or all shared 
> libraries when attempting its check for broken libraries in a Portfile? I 
> have some Java software which is precompiled and also delivering some 
> additional shared libraries. Unfortunately, MacPorts is incorrectly detecting 
> some of the shared libraries as broken and attempting to recompile the 
> package.

You can't disable it on a per-port basis, but you can prevent
rev-upgrade from running automatically, or put it in report-only mode,
with settings in macports.conf.

If it is indeed incorrectly considering some files broken, that is a bug
that we should fix, so please file a ticket. (Have you checked that the
detected brokenness could not be fixed with install_name_tool like e.g.
oracle-instantclient does?)

- Josh

Re: gnucash not finding dbus

[Lenore Horner]

> On Jun 20, 2018, at 04:26, Ryan Schmidt  wrote:
> 
> 
> On Jun 19, 2018, at 21:05, Lenore Horner wrote:
> 
>> On Jun 11, 2018, at 17:57, Lenore Horner wrote:
>> 
>>> gnucash is saying
>>> Dynamic session lookup supported but failed: launchd did not provide a 
>>> socket path, verify that org.freedesktop.dbus-session.plist is loaded!
>>> 
>>> but when I try to start dbus—session I get
>>> /opt/local/Library/LaunchAgents/org.freedesktop.dbus-session.plist: service 
>>> already loaded
>>> 
>>> so why isn’t gnucash seeing it?  
>> 
>> No one else is seeing this behavior and no one has any clue how to fix it?
> 
> Does unloading and then loading that plist help?
> 
I tried that and now the plist can’t even be found.  I ended up uninstalling 
dbus and reinstalling and then loading (w/o sudo as currently advised).  I 
notice that we used to be told that dbus had created start-up items but they 
were not enabled by default.  Now we’re told start-up items were not created.  
Does that mean I’ll have to re-issued the load commands for dbus every time I 
restart my computer now?  
Thanks,
Lenore

Re: Odd mpv configure series failure following fresh reinstall

[Rainer Müller]

On 2018-06-20 03:19, Lee Bast wrote:
>   Just wanted to give a small follow up: in the end I think the mpv port 
> is just entirely broken for me. I kept trying things until I ended up doing a 
> total fresh install again following updating to Xcode 9.4. Starting entirely 
> from scratch and just doing a plain "port install mpv" with no variants or 
> anything else installed first I still get the exact same error where 
> configure fails on
> 
>> :info:configure Checking for Lua 
>>  : no ('lua-5.2 >= 5.2.0' not found) 

Just checking, is the lua52 port installed and active?

$ port installed lua52
The following ports are currently installed:
  lua52 @5.2.4_1 (active)

> It looks like MacPorts' mpv is about a year old now so it might just be 
> related to age, and since ticket #54867 is already accepted for updating it 
> at some point I'm not sure if there is any point in opening a new ticket 
> until that's done. Once it's updated maybe that'll resolve it by itself. 
> Although Ken indicated it built, so yeah, not really sure what else to try if 
> a clean install fails as the first port, although I'd be happy to give it a 
> shot if there are suggestions.
> 
> Fresh install log but nothing particularly interesting I think. Also thanks 
> again for your earlier reply Ken!

The problem can probably only be debugged further by looking into
config.log, which contains the details how and where mpv expected to
find Lua. Use this command to find this file after the failed build attempt:

$ find $(port work mpv) -name config.log

Also, to make another guess on what is going on, what is the result of
the following command on your system?

$ pkg-config --libs --cflags lua-5.2
-I/opt/local/include/lua-5.2 -L/opt/local/lib/lua-5.2 -llua-5.2 -lm

Rainer

Re: Preventing check of sharedlibs in rev-upgrade

[Richard L. Hamilton]

> On Jun 20, 2018, at 07:34, Joshua Root  wrote:
> 
> Artur Szostak wrote:
>> Is there any way of telling MacPorts to not consider one, more or all shared 
>> libraries when attempting its check for broken libraries in a Portfile? I 
>> have some Java software which is precompiled and also delivering some 
>> additional shared libraries. Unfortunately, MacPorts is incorrectly 
>> detecting some of the shared libraries as broken and attempting to recompile 
>> the package.
> 
> You can't disable it on a per-port basis, but you can prevent
> rev-upgrade from running automatically, or put it in report-only mode,
> with settings in macports.conf.
> 
> If it is indeed incorrectly considering some files broken, that is a bug
> that we should fix, so please file a ticket. (Have you checked that the
> detected brokenness could not be fixed with install_name_tool like e.g.
> oracle-instantclient does?)
> 
> - Josh
> 

And if you just want to disable it sometimes, there's an option for that:

port upgrade --no-rev-upgrade outdated


signature.asc
Description: Message signed with OpenPGP

Re: Preventing check of sharedlibs in rev-upgrade

[Joshua Root]

Artur Szostak wrote:
> Is there any way of telling MacPorts to not consider one, more or all shared 
> libraries when attempting its check for broken libraries in a Portfile? I 
> have some Java software which is precompiled and also delivering some 
> additional shared libraries. Unfortunately, MacPorts is incorrectly detecting 
> some of the shared libraries as broken and attempting to recompile the 
> package.

You can't disable it on a per-port basis, but you can prevent
rev-upgrade from running automatically, or put it in report-only mode,
with settings in macports.conf.

If it is indeed incorrectly considering some files broken, that is a bug
that we should fix, so please file a ticket. (Have you checked that the
detected brokenness could not be fixed with install_name_tool like e.g.
oracle-instantclient does?)

- Josh

Preventing check of sharedlibs in rev-upgrade

[Artur Szostak]

Hello,

Is there any way of telling MacPorts to not consider one, more or all shared 
libraries when attempting its check for broken libraries in a Portfile? I have 
some Java software which is precompiled and also delivering some additional 
shared libraries. Unfortunately, MacPorts is incorrectly detecting some of the 
shared libraries as broken and attempting to recompile the package.

Kind regards.

Artur

Re: gnucash not finding dbus

[Ryan Schmidt]

On Jun 19, 2018, at 21:05, Lenore Horner wrote:

> On Jun 11, 2018, at 17:57, Lenore Horner wrote:
> 
>> gnucash is saying
>> Dynamic session lookup supported but failed: launchd did not provide a 
>> socket path, verify that org.freedesktop.dbus-session.plist is loaded!
>> 
>> but when I try to start dbus—session I get
>> /opt/local/Library/LaunchAgents/org.freedesktop.dbus-session.plist: service 
>> already loaded
>> 
>> so why isn’t gnucash seeing it?  
> 
> No one else is seeing this behavior and no one has any clue how to fix it?

Does unloading and then loading that plist help?