Re: nested port upgrading and variants

2016-10-27 Thread Marko Käning 
Hi folks,

thanks René, for reporting, but ...

On 27 Oct 2016, at 21:59 , René J.V. Bertin  wrote:
> On Thursday October 27 2016 14:55:59 Ryan Schmidt wrote:
> 
>>> That's what I told Marko too, but we're not talking here about the initial 
>>> installation. I think that when you already have opencv+qt5+opencv 
>>> installed, an automatic upgrade to opencv should behave like `port upgrade 
>>> opencv`. IOW, it should maintain the active variants. Anything else is a 
>>> waste of time and source of frustration.
>> 
>> I'm not aware of any reason why that wouldn't happen. MacPorts preserves 
>> variants on upgrades.
> 
> And neither do I see any reason why the use of the active_variants portgroup 
> would change anything in this matter, but one can never be too sure.
> 
> Let's see what Marko has to tell us about the exact command he used that led 
> to opencv being upgraded without its current variants.

I’ve to see whether I can resurrect some snapshot where I hadn’t updated opencv 
yet to check whether I can reproduce the oddity.

I’ll come back to you soonish, but not very quick, as I am absorbed with other 
more pressing stuff right now.

Till then,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

port:libcxx : use via DYLD_INSERT_LIBRARIES

2016-10-27 Thread René J . V . Bertin 
Hi,

I've built and been testing the libraries from port:libcxx 3.7.1 for a while 
now, on OS X 10.9.5 . I didn't take the completely adventurous approach; 
instead, I copied them into a new directory (/opt/lib) and wrote a little 
wrapper script that inserts them before loading any application.

I would expect these libraries to be backwards compatible, so that C++ apps 
built on/for an older OS still run on a newer OS. Indeed, most applications run 
fine; either identically or without the dynamic_cast errors that I see with 
some KDE software on 10.9 .

However, a few applications don't run (properly) at all, or crash. QtWebEngine 
5.7 crashes with memory allocation errors, and Opera fails to render pages. 
Both are based on Chromium. Does anyone know if this is to be expected?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: nested port upgrading and variants

2016-10-27 Thread René J . V . Bertin 
On Thursday October 27 2016 14:55:59 Ryan Schmidt wrote:

> > That's what I told Marko too, but we're not talking here about the initial 
> > installation. I think that when you already have opencv+qt5+opencv 
> > installed, an automatic upgrade to opencv should behave like `port upgrade 
> > opencv`. IOW, it should maintain the active variants. Anything else is a 
> > waste of time and source of frustration.
> 
> I'm not aware of any reason why that wouldn't happen. MacPorts preserves 
> variants on upgrades.

And neither do I see any reason why the use of the active_variants portgroup 
would change anything in this matter, but one can never be too sure.

Let's see what Marko has to tell us about the exact command he used that led to 
opencv being upgraded without its current variants.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: nested port upgrading and variants

2016-10-27 Thread Ryan Schmidt 

> On Oct 27, 2016, at 1:28 PM, René J.V. Bertin  wrote:
> 
> On Thursday October 27 2016 11:12:10 David Strubbe wrote:
> 
> Hi David,
> 
> 
>> used for a dependency. That's all it does. The only way I know of that you
>> could make opencv get installed with +qt5 in this context is to do "port
>> install kf5-digikam-devel +qt5" (whether that is a meaningful variant for
>> kf5-digikam-devel or not).
> 
> That's what I told Marko too, but we're not talking here about the initial 
> installation. I think that when you already have opencv+qt5+opencv installed, 
> an automatic upgrade to opencv should behave like `port upgrade opencv`. IOW, 
> it should maintain the active variants. Anything else is a waste of time and 
> source of frustration.

I'm not aware of any reason why that wouldn't happen. MacPorts preserves 
variants on upgrades.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: nested port upgrading and variants

2016-10-27 Thread David Strubbe 
I agree with you about what should happen. I just wanted to clarify that
the active_variants portgroup doesn't make that happen, and probably cannot
-- this is a base issue.

On Thu, Oct 27, 2016 at 11:28 AM, René J.V. Bertin 
wrote:

> On Thursday October 27 2016 11:12:10 David Strubbe wrote:
>
> Hi David,
>
>
> >used for a dependency. That's all it does. The only way I know of that you
> >could make opencv get installed with +qt5 in this context is to do "port
> >install kf5-digikam-devel +qt5" (whether that is a meaningful variant for
> >kf5-digikam-devel or not).
>
> That's what I told Marko too, but we're not talking here about the initial
> installation. I think that when you already have opencv+qt5+opencv
> installed, an automatic upgrade to opencv should behave like `port upgrade
> opencv`. IOW, it should maintain the active variants. Anything else is a
> waste of time and source of frustration.
>
> R.
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: nested port upgrading and variants

2016-10-27 Thread René J . V . Bertin 
On Thursday October 27 2016 11:12:10 David Strubbe wrote:

Hi David,


>used for a dependency. That's all it does. The only way I know of that you
>could make opencv get installed with +qt5 in this context is to do "port
>install kf5-digikam-devel +qt5" (whether that is a meaningful variant for
>kf5-digikam-devel or not).

That's what I told Marko too, but we're not talking here about the initial 
installation. I think that when you already have opencv+qt5+opencv installed, 
an automatic upgrade to opencv should behave like `port upgrade opencv`. IOW, 
it should maintain the active variants. Anything else is a waste of time and 
source of frustration.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: nested port upgrading and variants

2016-10-27 Thread David Strubbe 
Hi René,

The purpose of the active_variants portgroup is to provide error messages
like the one you mentioned, after checking whether a certain variant was
used for a dependency. That's all it does. The only way I know of that you
could make opencv get installed with +qt5 in this context is to do "port
install kf5-digikam-devel +qt5" (whether that is a meaningful variant for
kf5-digikam-devel or not).

David

On Thu, Oct 27, 2016 at 3:15 AM, René J.V. Bertin 
wrote:

> Hi,
>
> Marko tells me he's been having issues with upgrading one of my KF5 ports
> that uses the active_variants portgroup to "depend" on variants of one of
> its dependencies.
>
> From our exchange:
>
> > > >> BUT that’s not all yet. Once also needs to select the +contrib
> variant,
> > > >> otherwise you have to run another loop of building this port!
> Annoying
> > > >> is
> > > >> the word. What’s the reason for this odd behaviour?
> > > >
> > > > There's little I can do about that. digiKam needs +qt5 (evidently)
> but
> > > > also +contrib. The only way to increase the chance that opencv is
> > > > installed with those variants by default is to add the variants to
> > > > digikam, but that doesn't make a lot of sense. This is due to the
> fact
> > > > that ports cannot depend on the variants of another port (unless they
> > > > have the same variant, but that's propagation, not dependance). They
> > > > can only raise an error if they detect that a dependency is installed
> > > > with the wrong variant(s).
>
> In short: digikam needs port:opencv with +qt5+contrib. I try to impose
> that using
>
> {{{
> PortGroup   active_variants 1.1
>
> depends_lib-append  port:opencv
> require_active_variants opencv qt5
> require_active_variants opencv contrib
> }}}
>
> From what I understand, Marko had opencv+qt5+contrib installed and lost
> those variants when port:opencv was upgraded.
>
> I'll leave it to him to post the exact command he used for installing or
> upgrading the kf5-digikam port which led to the variant issue, I only have
> a part of the trace:
>
> {{{
> --->  Fetching archive for opencv
> --->  Attempting to fetch opencv-3.1.0_4.darwin_15.x86_64.tbz2 from
> http://nue.de.packages.macports.org/opencv
> --->  Attempting to fetch opencv-3.1.0_4.darwin_15.x86_64.tbz2 from
> https://packages.macports.org/opencv
> --->  Attempting to fetch opencv-3.1.0_4.darwin_15.x86_64.tbz2 from
> http://lil.fr.packages.macports.org/opencv
> --->  Fetching distfiles for opencv
> --->  Verifying checksums for opencv
> --->  Extracting opencv
> --->  Applying patches to opencv
> --->  Configuring opencv
> --->  Building opencv
> --->  Staging opencv into destroot
> --->  Installing opencv @3.1.0_4
> --->  Activating opencv @3.1.0_4
> --->  Cleaning opencv
> --->  Fetching archive for kf5-digikam-devel
> Error: org.macports.archivefetch for port kf5-digikam-devel returned:
> opencv must be installed with +qt5.
> Please see the log file for port kf5-digikam-devel for details:
> /opt/local/var/macports/logs/_Users_marko_WC_GIT_macstrop_
> kf5_kf5-digikam/kf5-digikam-devel/main.log
> }}}
>
> is there something wrong in my way of declaring the variant dependency, or
> is this to be expected?
>
> Thanks,
> René
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Review request for new-port ticket #50421 (wallet @1.3)

2016-10-27 Thread A. Karl Kornel 
Good morning! 

Would someone mind checking out ticket #50421?  This is a new port
submission I posted a while ago, but it hasn't been acted on. 

There are a number of patches, but they have been accepted upstream, so
when the next release happens the number of patches should be much lower
(assuming nothing else breaks!). 

Please let me know if there's anything else I need to do or change. 
Thanks much!

-- 
~ Karl Kornel___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Fwd: [154314] trunk/dports/security/paperkey/Portfile

2016-10-27 Thread Lawrence Velázquez 
Please do not commit version updates to my openmaintainer ports. I don't 
consider such changes "minor".

vq


> Begin forwarded message:
> 
> From: not...@macports.org
> Subject: [154314] trunk/dports/security/paperkey/Portfile
> Date: October 27, 2016 at 1:46:10 PM EDT
> To: macports-chan...@lists.macosforge.org
> Reply-To: macports-dev@lists.macosforge.org, not...@macports.org
> 
> Revision
> 154314 Author
> not...@macports.org Date
> 2016-10-27 19:46:10 +0200 (Thu, 27 Oct 2016)
> Log Message
> 
> paperkey: Update to 1.4
> Modified Paths
> 
> trunk/dports/security/paperkey/Portfile 
> 
> Diff
> 
>  <>Modified: trunk/dports/security/paperkey/Portfile (154313 => 154314)
> 
> --- trunk/dports/security/paperkey/Portfile   2016-10-27 16:22:34 UTC (rev 
> 154313)
> +++ trunk/dports/security/paperkey/Portfile   2016-10-27 17:46:10 UTC (rev 
> 154314)
> @@ -4,7 +4,7 @@
>  PortSystem  1.0
>  
>  namepaperkey
> -version 1.3
> +version 1.4
>  categories  security
>  platforms   darwin
>  license GPL-3+
> @@ -19,5 +19,5 @@
>  homepagehttp://www.jabberwocky.com/software/paperkey/ 
> 
>  
>  master_sites${homepage}
> -checksums   rmd160  b5849759b53ec55c39296b750cfafa5280248c03 \
> -sha256  
> 5b57d7522336fb65c4c398eec27bf44ec0aaa35926157b79a76423231792cbfb
> +checksums   rmd160  3a5c61a372b9442a0722e57f1aca5feaa43c7793 \
> +sha256  
> e12bb0ec835127d12a922a8d60b3dfdb3ca8ee60bb5b4d15ae4cea85bbcf336f
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org 
> 
> https://lists.macosforge.org/mailman/listinfo/macports-changes 
> 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:gpgme / Fwd: Review Request 129265: Port from KF5Gpgme to GpgME

2016-10-27 Thread René J . V . Bertin 
On Thursday October 27 2016 12:05:33 Rainer Müller wrote:

> Once again, our Trac is not hosted by GitHub.

I know, but logging in does involve github as far as I can tell. I restarted my 
login session, so I have to log in again.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

nested port upgrading and variants

2016-10-27 Thread René J . V . Bertin 
Hi,

Marko tells me he's been having issues with upgrading one of my KF5 ports that 
uses the active_variants portgroup to "depend" on variants of one of its 
dependencies.

From our exchange:

> > >> BUT that’s not all yet. Once also needs to select the +contrib variant,
> > >> otherwise you have to run another loop of building this port! Annoying
> > >> is
> > >> the word. What’s the reason for this odd behaviour?
> > > 
> > > There's little I can do about that. digiKam needs +qt5 (evidently) but
> > > also +contrib. The only way to increase the chance that opencv is
> > > installed with those variants by default is to add the variants to
> > > digikam, but that doesn't make a lot of sense. This is due to the fact
> > > that ports cannot depend on the variants of another port (unless they
> > > have the same variant, but that's propagation, not dependance). They
> > > can only raise an error if they detect that a dependency is installed
> > > with the wrong variant(s).

In short: digikam needs port:opencv with +qt5+contrib. I try to impose that 
using

{{{
PortGroup   active_variants 1.1

depends_lib-append  port:opencv
require_active_variants opencv qt5
require_active_variants opencv contrib
}}}

From what I understand, Marko had opencv+qt5+contrib installed and lost those 
variants when port:opencv was upgraded.

I'll leave it to him to post the exact command he used for installing or 
upgrading the kf5-digikam port which led to the variant issue, I only have a 
part of the trace:

{{{
--->  Fetching archive for opencv
--->  Attempting to fetch opencv-3.1.0_4.darwin_15.x86_64.tbz2 from 
http://nue.de.packages.macports.org/opencv
--->  Attempting to fetch opencv-3.1.0_4.darwin_15.x86_64.tbz2 from 
https://packages.macports.org/opencv
--->  Attempting to fetch opencv-3.1.0_4.darwin_15.x86_64.tbz2 from 
http://lil.fr.packages.macports.org/opencv
--->  Fetching distfiles for opencv
--->  Verifying checksums for opencv
--->  Extracting opencv
--->  Applying patches to opencv
--->  Configuring opencv
--->  Building opencv
--->  Staging opencv into destroot
--->  Installing opencv @3.1.0_4
--->  Activating opencv @3.1.0_4
--->  Cleaning opencv
--->  Fetching archive for kf5-digikam-devel
Error: org.macports.archivefetch for port kf5-digikam-devel returned: opencv 
must be installed with +qt5.
Please see the log file for port kf5-digikam-devel for details:

/opt/local/var/macports/logs/_Users_marko_WC_GIT_macstrop_kf5_kf5-digikam/kf5-digikam-devel/main.log
}}}

is there something wrong in my way of declaring the variant dependency, or is 
this to be expected?

Thanks,
René
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:gpgme / Fwd: Review Request 129265: Port from KF5Gpgme to GpgME

2016-10-27 Thread Rainer Müller 
On 2016-10-27 09:58, René J.V. Bertin wrote:
> I'm not getting into trac (github being DDoS'ed again??), so I'm forwarding 
> this info via the ML hoping Ryan will catch it.

Once again, our Trac is not hosted by GitHub.

This is still the same cause Clemens reported on yesterday. Please bear
with us while we are trying to find the right knobs to avoid these timeouts.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

port:gpgme / Fwd: Review Request 129265: Port from KF5Gpgme to GpgME

2016-10-27 Thread René J . V . Bertin 
Hi,

I'm not getting into trac (github being DDoS'ed again??), so I'm forwarding 
this info via the ML hoping Ryan will catch it.

First, gpgme has been updated to 1.7.1 which apparently brings bug fixes we 
"definitely want".

But more importantly, KDE is dropping the use of its own version of gpgme++. 
This was apparently already decided when we had the discussion about the header 
clashes (a known problem, clearly): https://git.reviewboard.kde.org/r/129265/ 
Had I known about that I wouldn't have suggested to move the C++ headers in 
port:gpgme, evidently.

>From what I understand of the discussion on the above RR ticket and the ML 
>post it refers to, the transition should be transparent for KF5 ports once we 
>(I) drop the KF5Gpgme port, at least after a transitional period. The clash 
>with the KDEPIM4 headers will persist, evidently, but should be limited to 
>those ports.

René
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev