Re: [MacPorts] #54009: libsndfile @1.0.27: update to 1.0.28

[Ryan Schmidt]

Yes, I would include as much of

https://github.com/erikd/libsndfile/commit/170a10ab8d4e6e395e68ee258edb077e80c1215d

as is relevant to fix this issue (i.e. not the part that changes the version 
number). You'll then need to "use_autoreconf yes" too, since the patch modify 
configure.ac and configure will need to be regenerated. If the project uses an 
autogen.sh script, use that instead.

-Ryan


> On Apr 26, 2017, at 02:43, Jan Stary  wrote:
> 
> libsndfile 1.0.28 has introduced "-Wvla" into its compilation options,
> which means it no longer builds on my 10.6.8 which comes with gcc 4.2.1.
> 
>  cc1: error: unrecognized command line option "-Wvla"
> 
> I brought that up on the sndfile mailing list,
> upstream already has a fix for it in their git
> (i.e. check first that the compiler support -Wvla).
> 
> It builds fine with e.g. gcc-4.3 that comes with macports.
> 
> Until upstreams releases the fixed version, what do I do?
> Rather than messing with the choice of compiler (which I never did before),
> I would just patch the -Wvla away.
> 
> Are there any objections to that?
> (I thought I would ask here before posting the Portfile diff).
> 
>   Jan
> 
> 
> 
>> #54009: libsndfile @1.0.27: update to 1.0.28
>> --+
>> Reporter:  l2dy  |  Owner:  janstary
>> Type:  update| Status:  new
>> Priority:  Normal|  Milestone:
>> Component:  ports |Version:
>> Keywords:  security  |   Port:  libsndfile
>> --+
>> CVE-2017-7585 CVE-2017-7586 CVE-2017-7741 CVE-2017-7742.
>> 
>> All low impact from Red Hat CVE Database.

Re: [macports-ports] branch master updated: emacs-mac-app: add missing build dep

[Ryan Schmidt]

> On Apr 25, 2017, at 15:21, Sean Farley  wrote:
> 
> Sean Farley (seanfarley) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/ff1f457e8fc9ad431f2d1b77b13e32243209b96d
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new ff1f457  emacs-mac-app: add missing build dep
> 
> ff1f457 is described below
> 
> 
> commit ff1f457e8fc9ad431f2d1b77b13e32243209b96d
> 
> Author: Sean Farley 
> AuthorDate: Tue Apr 25 13:21:18 2017 -0700
> 
> 
> emacs-mac-app: add missing build dep
> 
> 
> 
> Closes: https://trac.macports.org/ticket/54039
> 
> ---
>  aqua/emacs-mac-app/Portfile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> 
> diff --git a/aqua/emacs-mac-app/Portfile b/aqua/emacs-mac-app/Portfile
> 
> index d25f09f..2004e2f7 100644
> 
> --- a/aqua/emacs-mac-app/Portfile
> 
> +++ b/aqua/emacs-mac-app/Portfile
> 
> @@ -9,6 +9,7 @@ set emacs_mac_ver   6.3
> 
>  bitbucket.setup mituharu emacs-mac 
> emacs-${emacs_version}-mac-${emacs_mac_ver}
>  nameemacs-mac-app
>  version ${emacs_mac_ver}
> 
> +revision1
> 
>  categories  aqua editors
>  maintainers nomaintainer
>  
> 
> @@ -35,7 +36,7 @@ universal_variant   no
> 
>  use_autoreconf  yes
>  autoreconf.cmd  ./autogen.sh
>  
> 
> -depends_build   port:autoconf port:automake port:libtool
> 
> +depends_build   port:autoconf port:automake port:libtool port:texinfo
> 
>  
>  configure.args  --with-mac \
>  --enable-mac-app=${applications_dir} \
> 
> 

You don't generally need to increase the revision for build failures. Doing so 
only makes everyone who already had the port installed (because they already 
happened to have the missing dependency installed) unnecessarily rebuild the 
port.

Re: "dev" ports (=/= "devel" ports!)

[René J . V . Bertin]

On Wednesday April 26 2017 17:32:58 Rainer Müller wrote:

> source, but skip the compilation with pre-compiled archives. These are
> not real packages, as they cannot be installed standalone without a
> source ports tree.

Hmm? You mean the Portfiles? That's not really different from Debian and 
presumably RPM-based systems, which also have a local database that tells them 
which packages are available (and that usually allow to install from source 
too).

One fundamental difference with Debuntu and RPM packaging (AFAIK) is that those 
always involve the binary package (.deb or .rpm file). Even if you build a 
package from source that is part of a source package generating 10 other 
packages you'll end up with all those .deb or .rpm files somewhere, but install 
only that single package plus its dependencies.

> I do not understand how your provided Port Group is supposed to work,
> because 'create_devport_content_archive' is not called anywhere.

Well, that's because even for "dev" content it's a bit too port-specific what 
qualifies so the ultimate archive creation step has to be made explicitly in 
the Portfile. For instance in my Linux version of port:tiff :

{{{
post-destroot {
if {${subport} eq "${name}"} {
register_devport_standard_content
devport_content-append ${prefix}/share/doc/tiff/html
devport_content-append ${prefix}/share/man/man3
create_devport_content_archive
}
}
}}}

The register_devport_standard_content step could indeed be done in the 
PortGroup, though that would mean that the port cannot modify things in that 
standard content in its post-destroot .

> subport. This is a bad hack and is way too fragile, as de-/activate on
> the subport will inherently be broken, unless the main port is active.
> 

Why? Installing from the custom tarball uses the same kind of install mechanism 
that ports use that install content not needing any building: the file tree is 
created under $destroot in the destroot step, which is then installed as usual. 
Believe me I've tested the subport de/activation as that was the whole point of 
the endeavour. Being able to avoid build conflicts by (temporarily) removing 
just the files that could affect a build, not the runtime files.
That's also why I can remove the custom tarball once the -dev port is 
installed: it isn't needed anymore (and can be regenerated by de/re-activating 
the main port).

> The way this is done with other systems is to destroot once, then put
> files as specified into separate packages. Each resulting package can
> then be installed just as any other package.

The only difference here is that I'm not (yet) creating anything that looks 
like official packages, but put install certain files in latent fashion.

Which reminds me that another way to achieve this particular goal would be to 
move (hide) those files without archiving them, and then set up symlinks as 
appropriate in the -dev port's destroot phase.

> The way this could work in MacPorts would be to have a new phase for
> packaging after destroot and create multiple binary archives from one
> Portfile. ...
> Since
> everything will need to be built anyway, we can install and register all
> packages in the local system, but only activate the requested subport.

Maybe we're thinking along the same lines, but what I'd do is modify the 
existing phase that comes after the post-destroot. Currently that involves 
installing ${subport} from everything that is found under $destroot . It should 
be relatively straightforward to extend this to support multiple destroot 
directories. To stick with the -dev port example, you'd
- associate port:foo-dev (${subport}==${name}-dev) with "${destroot}-dev"
- during the usual install, MacPorts now installs the $destroot dir as ${name} 
(port:foo) and ${destroot}-dev as ${name}-dev (port:foo-dev).
- Of those two, only the one(s) of which an install or upgrade was requested 
(or that were active before) are activated; the other(s) are not.

There may be side-effects here that I am overlooking and I don't know if it is 
any simpler implementation-wise, but it does seem to fit in well with the 
traditional MacPorts approach of just installing everything.

It's basically adding install labels that allow you to de/activate a port in 
one or more sections. That part will probably indeed have to be done in Base.

> On installing, port would first check for a binary archive and
> if it exists, it is downloaded and installed as usual. Only if it does

That's already what happens, no? 

> Instead of developing this in a port group, it seems much easier to me
> to do that in base, especially as this would become a new type of port
> besides the existing subports.

Or as I said, a new property that determines from what directory (sub)ports are 
assembled and whether they build as standalone ports.

Evidently there are other applications for split ports besides not installing 
development content unless it's needed. There 

Re: "dev" ports (=/= "devel" ports!)

[Rainer Müller]

On 2017-04-26 14:15, René J.V. Bertin wrote:
>> I really really don't think a PortGroup is the right way to do
>> this. This should be done in base, with proper support of creating
>> multiple packages from a single build and then optionally
>> installing some of them, more like FreeBSD's ports does things.
> 
> As often I use a PortGroup only because it's a much more convenient
> way to develop and test new functionality, esp. the part that cannot
> be automated reliably anyway (indicating which files and directories
> have to go into the -dev port, or any number of "sub" ports).
> 
> We don't know how many ports would be using the feature, so why spend
> time and effort making possibly complex changes to Base until we know
> that?

In my opinion splits in the way they are done on Debian/Ubuntu or with
RPM distros makes a lot of sense for binary-only distributions. Ports
system work in a different way and usually do not implement such a
feature. At the moment, MacPorts is kind of a mix. You can install from
source, but skip the compilation with pre-compiled archives. These are
not real packages, as they cannot be installed standalone without a
source ports tree.

I do not understand how your provided Port Group is supposed to work,
because 'create_devport_content_archive' is not called anywhere.

But if I get it right, you want the main port to ship tarballs that
contain the files that will only be activated when installing the
subport. This is a bad hack and is way too fragile, as de-/activate on
the subport will inherently be broken, unless the main port is active.

The way this is done with other systems is to destroot once, then put
files as specified into separate packages. Each resulting package can
then be installed just as any other package.

The way this could work in MacPorts would be to have a new phase for
packaging after destroot and create multiple binary archives from one
Portfile. On installing, port would first check for a binary archive and
if it exists, it is downloaded and installed as usual. Only if it does
not exist, we need to do build/destroot/package the parent port. Since
everything will need to be built anyway, we can install and register all
packages in the local system, but only activate the requested subport.

Instead of developing this in a port group, it seems much easier to me
to do that in base, especially as this would become a new type of port
besides the existing subports.

For the syntax, I would recommend to look at the way RPM allows to
define splits/sub-packages.

> There's also the point that ports using this particular new feature
> would impose users to upgrade if it's implemented in Base. I don't
> know if that'd be a precedent, but wouldn't like it if it is. I'd
> prefer to see Base as a kind of microkernel with a modular
> architecture (but that's just me).

New features have always been part of base. What you want to do is
something base was not designed for, so the framework needs to be extended.

Rainer

Re: Carthage Build Failure on BuildBot

[Rainer Müller]

On 2017-04-26 16:36, Zero King wrote:
> Cloning into 'Carthage/Checkouts/Argo'...
> fatal: unable to access 'https://github.com/thoughtbot/Argo.git/': SSL
> certificate problem: Couldn't understand the server certificate format
> fatal: clone of 'https://github.com/thoughtbot/Argo.git' into submodule
> path 'Carthage/Checkouts/Argo' failed
> 
> Cloning into 'Carthage/Checkouts/Argo'...
> fatal: unable to access 'https://github.com/thoughtbot/Argo.git/':
> Unknown SSL protocol error in connection to github.com:-67674
> Clone of 'https://github.com/thoughtbot/Argo.git' into submodule path
> 'Carthage/Checkouts/Argo' failed

Others have reported the same failure outside of the buildbot, but no
cause has been identified yet:

https://trac.macports.org/ticket/53629

Rainer

Re: "dev" ports (=/= "devel" ports!)

[René J . V . Bertin]

On Wednesday April 26 2017 13:32:47 Clemens Lang wrote:

Hi,


> I really really don't think a PortGroup is the right way to do this. This 
> should
> be done in base, with proper support of creating multiple packages from a 
> single
> build and then optionally installing some of them, more like FreeBSD's ports
> does things.

As often I use a PortGroup only because it's a much more convenient way to 
develop and test new functionality, esp. the part that cannot be automated 
reliably anyway (indicating which files and directories have to go into the 
-dev port, or any number of "sub" ports).

We don't know how many ports would be using the feature, so why spend time and 
effort making possibly complex changes to Base until we know that? 

There's also the point that ports using this particular new feature would 
impose users to upgrade if it's implemented in Base. I don't know if that'd be 
a precedent, but wouldn't like it if it is. I'd prefer to see Base as a kind of 
microkernel with a modular architecture (but that's just me).

R

Re: "dev" ports (=/= "devel" ports!)

[Jan Stary]

On Apr 23 15:54:07, rjvber...@gmail.com wrote:
> I'd like to draw some attention to a prototype implementation of a PortGroup 
> I wrote for creating "dev" ports, akin to Debian/Ubuntu's "-dev" packages:
> https://trac.macports.org/ticket/52713

> I've been using this for a while now and find it particularly useful for 
> avoiding build conflicts. That kind of conflict usually arises when the 
> presence of certain files from a port A interferes with building port B. Most 
> often that concerns headerfiles but "linker interface" libraries can also be 
> at cause, or even pkgconfig/cmake files.

Can you please describe the motivating situation in detail,
i.e. what header files were conflicting with what?

Also, I am not entirely clear on what you mean by
"link libraries" (as opposed to "libraries").

I remember from my Debian days (long ago) how strange this felt.
I have installed, say, libpng. So there is /usr/local/libpng.so
and the programs that need png run hapilly. But I cannot write
any program that uses the library, because? There is no png.h;
I need to install a separate libpng-dev for that.

Please don't. Or at least only in very specific cases that need it.
Even if one library's header file(s) conflict with other library's
header file (example?), the solution is imho not to not install the
header files.

Have one port, say 'png', that installs the library, the headers,
and the manpages. Please don't go the Debian way where a modest
workstation needs to have hundreds of packages installed.

> Those are all files that are only required when using port "A"
> as a dependency for *building* other software but not as a dependency
> for running that dependent software.

The keyword here is "only". It is not unusual to install a library
(and its header files, and its pkgconfig files, and its documentation)
because you want to develop software using that library.
Please don't make it needlessly complicated by requiring
more than one port to be installed.

I admit there are packeges where a separate -doc might be in order
(as a subport? or a variant? is there an agreement?) if the documentation
is considerably bigger than the library itself, or is just a copy
of a set of html pages to be found on the upstream's homepage.

> I think that it should even be possible to use this kind of approach for 
> ports that cannot be built when an older version is already installed; such 
> ports could probably declare a build conflict with their own -dev port 
> (possibly even deactivate it in an appropriate stage).

That's the kind of mess I'm talking about.
"Declare a build conflict with you own -dev port."
Please don't.

Jan

Re: [MacPorts] #54009: libsndfile @1.0.27: update to 1.0.28

[Jan Stary]

libsndfile 1.0.28 has introduced "-Wvla" into its compilation options,
which means it no longer builds on my 10.6.8 which comes with gcc 4.2.1.

  cc1: error: unrecognized command line option "-Wvla"

I brought that up on the sndfile mailing list,
upstream already has a fix for it in their git
(i.e. check first that the compiler support -Wvla).

It builds fine with e.g. gcc-4.3 that comes with macports.

Until upstreams releases the fixed version, what do I do?
Rather than messing with the choice of compiler (which I never did before),
I would just patch the -Wvla away.

Are there any objections to that?
(I thought I would ask here before posting the Portfile diff).

Jan



> #54009: libsndfile @1.0.27: update to 1.0.28
> --+
>  Reporter:  l2dy  |  Owner:  janstary
>  Type:  update| Status:  new
>  Priority:  Normal|  Milestone:
> Component:  ports |Version:
>  Keywords:  security  |   Port:  libsndfile
> --+
>  CVE-2017-7585 CVE-2017-7586 CVE-2017-7741 CVE-2017-7742.
> 
>  All low impact from Red Hat CVE Database.

Re: Opportunistic (broken) build dependencies? (gdbm)

[Joshua Root]

On 2017-4-26 10:32 , Marius Schamschula wrote:
However, gdbm is not in the dependency chain of gawk, so I don’t know 
why MacPorts wants to install it before gawk.


There is no dependency declared, so if you're upgrading all outdated 
ports, the ordering of these two is effectively random (as it's based on 
what other ports are outdated).


- Josh