Re: about alternative ports and the build bots

[Ryan Schmidt]

On Sep 28, 2015, at 8:59 AM, René J.V. Bertin wrote:

> In short, consider 2 ports that are supposed to be alternatives like port:foo 
> and port:foo-devel, but that are different enough in where they install 
> libraries that their binary forms are not drop-in replacements, and that 
> cannot of course be installed concurrently. To keep this generic, let's 
> assume there's a port:foo-mac which adheres to a Mac-inspired install layout 
> and port:foo-xdg which adheres to a layout that's compatible with the ones 
> used on Linux and other Unixes. Let's also assume that there as always been a 
> foo PortGroup that takes care of defining variables for the various install 
> locations, and that sets up a path: style dependency on port:foo (or one of 
> its alternatives). This PortGroup has been split into foo-mac, foo-kde 
> PortGroups and a general foo PortGroup that can include the appropriate foo 
> "sub PortGroup" as a function of what the user has installed or a preference 
> declared by a dependent port.

path:-style dependencies are for ports that are drop-in replacements for one 
another. You've given a prerequisite for this scenario that the ports you're 
talking about are *not* drop-in replacements for one another. Therefore you 
can't use path:-style dependencies, and should instead use conflicting 
variants, with one being default. The default one will be built by the buildbot 
builders; if the user uses the other variant, that won't match the signature of 
the binary so they'll build from source.

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

Re: Dist file mirror selection

[Joshua Root]

On 2015-9-29 11:50 , Craig Treleaven wrote:
> Hi:
> 
> What order does MacPorts use for fetching dist files?  My impression was that 
> MacPorts would try to:
> 
> 1) use a ‘close by’ mirror (based on ping times)
> 2) fetch from the main MacPorts dist file server 
> (http://distfiles.macports.org/)
> 3) fall back to the master_site (GitHub, in my case[a])

Nope, it goes completely by ping time (as modified by
host_blacklist/preferred_hosts) except in the case of
 which is tried
as a last resort.

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

Re: [140646] trunk/dports/cross/ppc-linux-binutils/Portfile

[Ryan Schmidt]

> On Sep 28, 2015, at 5:58 PM, take...@macports.org wrote:
> 
> Revision
> 140646
> Author
> take...@macports.org
> Date
> 2015-09-28 15:58:38 -0700 (Mon, 28 Sep 2015)
> Log Message
> 
> ppc-linux-binutils: update to 2.25

> Modified: trunk/dports/cross/ppc-linux-binutils/Portfile (140645 => 140646)

> +post-patch {
> +# fix Puma linking in configure on Yosemite
> +# cf. 
> http://fink.cvs.sourceforge.net/fink/dists/10.7/stable/main/finkinfo/devel/powerpc-binutils.info?view=markup
> +foreach f [glob -directory ${worksrcpath} */configure] {
> +reinplace {s|10\.\[012\]\*|10.[012][,.]*|g} ${f}
> +}
> +}

This should be a patchfile rather than a reinplace, for the usual reasons.

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

Dist file mirror selection

[Craig Treleaven]

Hi:

What order does MacPorts use for fetching dist files?  My impression was that 
MacPorts would try to:

1) use a ‘close by’ mirror (based on ping times)
2) fetch from the main MacPorts dist file server 
(http://distfiles.macports.org/)
3) fall back to the master_site (GitHub, in my case[a])

That didn’t happen, at least for one user, viz:

--->  mythtv-e9b577d3.tar.gz doesn't seem to exist in 
/opt/local/var/macports/distfiles/mythtv-core.27
--->  Attempting to fetch mythtv-e9b577d3.tar.gz from 
https://github.com/MythTV/mythtv/tarball/e9b577d3

Why did it go GitHub rather than one of our mirrors (or the main site)?

Craig

[a] See ticket 48987 if you want the details.  I believe a git hook is run when 
the snapshot is being prepared and it behaves differently at different times. 
I’m trying to work with upstream to figure out when and why it changes.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with the portgroup python

[Joshua Root]

On 2015-9-29 01:33 , Tiago Freitas Pereira wrote:
> Hi,
> 
> I'm developing a port using the portgroup python (called py-bob).
> 
> Executing some tests locally, I can install successfully the port using
> the commands 
> {{{
> sudo port install py27-bob #for python 2.7
> }}}
> or 
> {{{
> sudo port install py34-bob #for python 3.4
> }}}
> 
> However, if I do 
> {{{
> sudo port install py-bob
> }}}
> macports installs the py-bob package (python 2.7 (set as default))
> without their python dependencies (even if the python.default_version is
> set to 27).
> 
> The portfile is attached.
> 
> I'm not sure if I completely understood the execution flow using this
> portgroup, but as far as I understood, when the user tries to install
> the py-bob, macports redirects to the correspondent subport  (in this
> case, again, python 2.7) for the port itself and for the python
> dependencies. Am I right?

py-bob would depend on py27-bob, but you are overwriting this dependency
by using depends_lib rather than depends_lib-append. There's really no
point having py-bob depend on anything else, so you should just move the
addition of all the deps into the subports as in the attached patch.

- Josh
--- Portfile.current	2015-09-29 01:44:33.0 +1000
+++ Portfile.new	2015-09-29 01:50:37.0 +1000
@@ -34,25 +34,22 @@
  sha256  626fab4953759f5e65e7532e7e73396eb54278226ec89049f66f6b8f11b5aa97
 
 
-depends_build-append port:pkgconfig
-
-
-depends_lib port:blitz \
-path:lib/libavcodec.dylib:ffmpeg \
-port:matio \
-port:jpeg \
-port:netpbm \
-port:libpng \
-port:tiff \
-port:giflib \
-port:hdf5 \
-port:fftw-3 \
-port:vlfeat \
-port:libsvm
-
 if {$subport ne $name} {
+depends_build-append port:pkgconfig
 
 depends_lib-append  \
+  port:blitz \
+  path:lib/libavcodec.dylib:ffmpeg \
+  port:matio \
+  port:jpeg \
+  port:netpbm \
+  port:libpng \
+  port:tiff \
+  port:giflib \
+  port:hdf5 \
+  port:fftw-3 \
+  port:vlfeat \
+  port:libsvm \
   port:py${python.version}-sphinx \
   port:py${python.version}-setuptools \
   port:py${python.version}-numpy \
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: about alternative ports and the build bots

[Jeremy Huddleston Sequoia]

The issue exists in more general form for cases like ffmpeg and ffmpeg-devel 
when the dylib id changes (eg: when bumping it due to binary incompatibility).  
If the user goes and installs ffmpeg-devel, then anything that depends on 
ffmpeg needs to be built from source because the buildbot produces content 
linked against ffmpeg.

I don't think there's really any way around this with MacPorts currently.

> On Sep 28, 2015, at 06:59, René J.V. Bertin  wrote:
> 
> Hi,
> 
> I'd like to bring up something related to alternative ports and the build 
> bots. It concerns my qt5-kde port (submitted on trac), but the principle is 
> more generic.
> 
> In short, consider 2 ports that are supposed to be alternatives like port:foo 
> and port:foo-devel, but that are different enough in where they install 
> libraries that their binary forms are not drop-in replacements, and that 
> cannot of course be installed concurrently. To keep this generic, let's 
> assume there's a port:foo-mac which adheres to a Mac-inspired install layout 
> and port:foo-xdg which adheres to a layout that's compatible with the ones 
> used on Linux and other Unixes. Let's also assume that there as always been a 
> foo PortGroup that takes care of defining variables for the various install 
> locations, and that sets up a path: style dependency on port:foo (or one of 
> its alternatives). This PortGroup has been split into foo-mac, foo-kde 
> PortGroups and a general foo PortGroup that can include the appropriate foo 
> "sub PortGroup" as a function of what the user has installed or a preference 
> declared by a dependent port.
> 
> So when building a port that depends on foo:
> - if foo-xdg is installed and foo.prefer_mac isn't defined, use the foo-xdg 
> PortGroup
> - else if foo-mac is installed and foo.prefer_xdg isn't defined, use the 
> foo-mac PortGroup
> - else if foo.prefer_xdg is defined, use the foo-xdg PortGroup
> - else use the foo-mac PortGroup
> 
> From this it should follow that any port that does not declare a preference 
> will use the foo-mac PortGroup (pulling it in if necessary) unless the user 
> already installed port:foo-xdg .
> 
> If no binary builds existed, this should more or less cover all possible 
> cases. It would be nice to have the option to "prefer the one but can make do 
> with the other too" vs. "require the one over the other" (aborting when the 
> requirement is not met), but if that's even possible it can be a next 
> evolution.
> 
> Binary builds exist however, so something should be done to prevent pulling 
> in a binary build for (against) foo-mac when foo-kde is installed, and 
> vice-versa. I think I have a solution for that, which should work if my 
> assumption is correct that binary packages are built each starting with a 
> virgin MacPorts install, i.e. pulling in only the required dependencies.
> It works like this: the foo-xdg defines a `fooxdg` variant (if it doesn't 
> exist already), and makes it default. That way, any port that "inherits" 
> port:foo-xdg without requesting it specifically will get a (default) variant 
> that exists only on the user's end and not on the build bots, and therefore, 
> `port install somePortDependsOnFoo` will be a request for 
> somePortDependsOnFoo+fooxdg, leading to an install-from-source. On the other 
> hand, a port that prefers/requests foo-xdg will have the +fooxdg variant set 
> as a default also on the buildbots, and thus be available as a binary build 
> against port:foo-xdg .
> 
> The default_variant could be set only when the variant is defined in the 
> PortGroup or when foo.prefer_xdg is set, but I do not currently see why that 
> would be necessary or preferable.
> However, I'm not sure how best to ensure that someone with port:foo-mac 
> installed will not end up installing a binary package that is built against 
> port:foo-xdg , and I think that isn't already ensured. Maybe those ports 
> should simply do a pre-fetch check if foo-xdg is indeed the one installed 
> (via a proc to be provided by the foo-xdg PortGroup)?
> 
> 
> I think this is completely orthogonal to questions about reproducible builds, 
> before anyone mentions that principle :) and I can only hope that this is not 
> "MacPorts doesn't support this". (The real-world implementation of 
> port:foo-xdb, port:qt5-kde, is quite likely to be a requirement for KF5 ports 
> currently in preparation.)
> 
> Thoughts and feedback welcome!
> 
> R.
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Issues with the portgroup python

[Tiago Freitas Pereira]

Hi,

I'm developing a port using the portgroup python (called py-bob).

Executing some tests locally, I can install successfully the port using the
commands
{{{
sudo port install py27-bob #for python 2.7
}}}
or
{{{
sudo port install py34-bob #for python 3.4
}}}

However, if I do
{{{
sudo port install py-bob
}}}
macports installs the py-bob package (python 2.7 (set as default)) without
their python dependencies (even if the python.default_version is set to 27).

The portfile is attached.

I'm not sure if I completely understood the execution flow using this
portgroup, but as far as I understood, when the user tries to install the
py-bob, macports redirects to the correspondent subport  (in this case,
again, python 2.7) for the port itself and for the python dependencies. Am
I right?

Thank you very much in advance


-- 
Tiago


Portfile.current
Description: Binary data
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

about alternative ports and the build bots

[René J . V . Bertin]

Hi,

I'd like to bring up something related to alternative ports and the build bots. 
It concerns my qt5-kde port (submitted on trac), but the principle is more 
generic.

In short, consider 2 ports that are supposed to be alternatives like port:foo 
and port:foo-devel, but that are different enough in where they install 
libraries that their binary forms are not drop-in replacements, and that cannot 
of course be installed concurrently. To keep this generic, let's assume there's 
a port:foo-mac which adheres to a Mac-inspired install layout and port:foo-xdg 
which adheres to a layout that's compatible with the ones used on Linux and 
other Unixes. Let's also assume that there as always been a foo PortGroup that 
takes care of defining variables for the various install locations, and that 
sets up a path: style dependency on port:foo (or one of its alternatives). This 
PortGroup has been split into foo-mac, foo-kde PortGroups and a general foo 
PortGroup that can include the appropriate foo "sub PortGroup" as a function of 
what the user has installed or a preference declared by a dependent port.

So when building a port that depends on foo:
- if foo-xdg is installed and foo.prefer_mac isn't defined, use the foo-xdg 
PortGroup
- else if foo-mac is installed and foo.prefer_xdg isn't defined, use the 
foo-mac PortGroup
- else if foo.prefer_xdg is defined, use the foo-xdg PortGroup
- else use the foo-mac PortGroup

>From this it should follow that any port that does not declare a preference 
>will use the foo-mac PortGroup (pulling it in if necessary) unless the user 
>already installed port:foo-xdg .

If no binary builds existed, this should more or less cover all possible cases. 
It would be nice to have the option to "prefer the one but can make do with the 
other too" vs. "require the one over the other" (aborting when the requirement 
is not met), but if that's even possible it can be a next evolution.

Binary builds exist however, so something should be done to prevent pulling in 
a binary build for (against) foo-mac when foo-kde is installed, and vice-versa. 
I think I have a solution for that, which should work if my assumption is 
correct that binary packages are built each starting with a virgin MacPorts 
install, i.e. pulling in only the required dependencies.
It works like this: the foo-xdg defines a `fooxdg` variant (if it doesn't exist 
already), and makes it default. That way, any port that "inherits" port:foo-xdg 
without requesting it specifically will get a (default) variant that exists 
only on the user's end and not on the build bots, and therefore, `port install 
somePortDependsOnFoo` will be a request for somePortDependsOnFoo+fooxdg, 
leading to an install-from-source. On the other hand, a port that 
prefers/requests foo-xdg will have the +fooxdg variant set as a default also on 
the buildbots, and thus be available as a binary build against port:foo-xdg .

The default_variant could be set only when the variant is defined in the 
PortGroup or when foo.prefer_xdg is set, but I do not currently see why that 
would be necessary or preferable.
However, I'm not sure how best to ensure that someone with port:foo-mac 
installed will not end up installing a binary package that is built against 
port:foo-xdg , and I think that isn't already ensured. Maybe those ports should 
simply do a pre-fetch check if foo-xdg is indeed the one installed (via a proc 
to be provided by the foo-xdg PortGroup)?


I think this is completely orthogonal to questions about reproducible builds, 
before anyone mentions that principle :) and I can only hope that this is not 
"MacPorts doesn't support this". (The real-world implementation of 
port:foo-xdb, port:qt5-kde, is quite likely to be a requirement for KF5 ports 
currently in preparation.)

Thoughts and feedback welcome!

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