Re: man.macports.org

[Clemens Lang]

Hi,

On Tue, Jun 27, 2017 at 01:37:12AM +0200, Rainer Müller wrote:
> Hello,
> 
> I created a preliminary version of a linkable web version of our man pages:
> 
>   https://man.macports.org/port.1.html

Love it!


> If anyone would be willing to contribute a better CSS, that would be
> highly appreciated. For example, linkable anchors for headlines on
> hover (as on Trac) would be nice to have.

I'd love to do this, but realistically, I won't find time to. If anybody
wants to help out, that'd be awesome!

> Feedback welcome!

How are those updated? Are we using the master manpages?

-- 
Clemens

Re: [GSoC 2017] First Evaluation

[Umesh Singla]

Hello all,

I have prepared a small informal write up about the work and challenges
faced till now and posted on my blog [1]. Also, I have already completed my
side of evaluation and submitted on GSoC website.

Looking forward to community reviews.

Regards,
Umesh Singla

[1]:
https://umeshsingla.blogspot.in/2017/06/5-project-and-pre-first-evaluation.html

On Mon, Jun 26, 2017 at 9:42 PM, Jackson Isaac 
wrote:

>  Hi GSoC Students and Mentors,
>
> Phase 1 evaluation has started as of now until 16:00 UTC June 30,
> 2017. Please make sure that students fill out the mentor evaluations
> and at least one mentor evaluate the student performance before the
> deadline.
>
> It would be also good if the students can prepare a write-up about
> their work (code written) till now and further plans for 2nd phase.
>
> --
> Jackson Isaac
>

Re: [macports-ports] branch master updated: liblas: bump to 1.8.1

[mf2k]

Hi Vince,


See below.

> On Jun 27, 2017, at 10:57 AM, Vincent  wrote:
> 
> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/3d0aac3095640e42fabc64de06f9e16427d2664f
>  
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 3d0aac3  liblas: bump to 1.8.1
> 3d0aac3 is described below
> 
> commit 3d0aac3095640e42fabc64de06f9e16427d2664f
> Author: Veence 
> AuthorDate: Tue Jun 27 18:56:52 2017 +0200
> 
> liblas: bump to 1.8.1
> ---
>  gis/liblas/Portfile | 18 ++
>  gis/liblas/files/patch-gt_citation_cpp.diff | 20 
>  2 files changed, 34 insertions(+), 4 deletions(-)
> 
> diff --git a/gis/liblas/Portfile b/gis/liblas/Portfile
> index 572af16..7483696 100644
> --- a/gis/liblas/Portfile
> +++ b/gis/liblas/Portfile
> @@ -4,7 +4,9 @@ PortSystem  1.0
>  PortGroup   cmake 1.0
>  
>  nameliblas
> -version 1.7.0
> +version 1.8.1
> +distnamelibLAS-${version}-src.tar

This is not the correct usage of distname (there should not be any 
encodings/compression in it), and it gets overridden later, and correctly, in 
the Portfile anyway. So this line should be removed. 

> +use_bzip2   yes
>  license BSD
>  categories  gis
>  maintainers gmail.com:venabled
> @@ -20,14 +22,22 @@ long_description \
>  homepagehttp://www.liblas.org/index.html
>  master_siteshttp://download.osgeo.org/liblas
>  
> -checksums   rmd160  74642d8a2eb302458e7e829eab733ba409725f87 \
> -sha256  
> e6b30c4530fef283e680fac59b199e1be6b96994fb663d08fd12838eef928277
> +checksums   rmd160  b397a8a1a108ea694f6fccbe8463636cff9a04d9 \
> +sha256  
> 9adb4a98c63b461ed2bc82e214ae522cbd809cff578f28511122efe6c7ea4e76
>  
>  distnamelibLAS-${version}
>  
> +patchfiles  patch-gt_citation_cpp.diff
>  configure.args-append \
> --DWITH_GEOTIFF=ON
> +-DWITH_GEOTIFF=ON \
> + -DWITH_GDAL=ON 
>  
>  depends_lib-append  port:boost \
>  port:gdal \
>  port:libgeotiff
> +
> +post-destroot {
> + exec install_name_tool -id ${prefix}/lib/liblas.2.4.0.dylib 
> ${destroot}${prefix}/lib/liblas.2.4.0.dylib
> + exec install_name_tool -id ${prefix}/lib/liblas_c.2.4.0.dylib 
> ${destroot}${prefix}/lib/liblas_c.2.4.0.dylib
> + exec install_name_tool -change "@rpath/liblas.3.dylib" 
> ${prefix}/lib/liblas.3.dylib ${destroot}${prefix}/lib/liblas_c.2.4.0.dylib
> +}
> diff --git a/gis/liblas/files/patch-gt_citation_cpp.diff 
> b/gis/liblas/files/patch-gt_citation_cpp.diff
> new file mode 100644
> index 000..c78a086
> --- /dev/null
> +++ b/gis/liblas/files/patch-gt_citation_cpp.diff
> @@ -0,0 +1,20 @@
> +--- src/gt_citation.cpp.orig 2017-06-27 18:51:08.0 +0200
>  src/gt_citation.cpp  2017-06-27 18:51:45.0 +0200
> +@@ -155,7 +155,7 @@
> + if(p1[0] == '\0' || p1[0] == '\n' || p1[0] == ' ')
> +   p1 --;
> + p2 = p1 - 1;
> +-while( p2>0 && (p2[0] == ' ' || p2[0] == '\0' || p2[0] == '\n') )
> ++while( p2>(char *)0 && (p2[0] == ' ' || p2[0] == '\0' || p2[0] == 
> '\n') )
> +   p2--;
> + if(p2 != p1 - 1)
> +   p1 = p2;
> +@@ -198,7 +198,7 @@
> + if(p1[0] == '\0' || p1[0] == '\n' || p1[0] == ' ')
> +   p1 --;
> + char* p2 = p1 - 1;
> +-while( p2>0 && (p2[0] == ' ' || p2[0] == '\0' || p2[0] == '\n') )
> ++while( p2>(char *)0 && (p2[0] == ' ' || p2[0] == '\0' || p2[0] == 
> '\n') )
> +   p2--;
> + if(p2 != p1 - 1)
> +   p1 = p2;
> 

Cheers!
Frank

Re: Buildbot now fails to build wine dependencies

[Ken Cunningham]

On 2017-06-27, at 2:31 AM, Ryan Schmidt wrote:

> We used to be able to build wine on the buildbot, but we aren't anymore:
> 
> https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/32791
> 
> The error occurs when installing dependencies, specifically cairo:


This would also be why the Travis build system won't build anything I put up 
lately with cairo listed as a dep.


> The cairo port has for years had both x11 and quartz variants that are both 
> enabled by default. The glib2 port recently got x11 and quartz variants 
> added, and they conflict with one another, as they do in most ports that have 
> them; the user must choose one or the other. The default is x11, as it is for 
> other ports that have this choice.

If deleting the +x11 and +quartz variants for cairo is for some reason not 
desirable in the end, perhaps they can be defaulted to work exclusively again, 
and match all the other ports. That would allow everything to work again.

K

Re: clean install simulation mode?

[René J . V . Bertin]

Ryan Schmidt wrote:


> Maybe if you describe the problem the user is experiencing, we can figure out
> why it's happening without needing to do what you're proposing.

Thanks, I appreciate that.

I'm still trying to figure out what that problem is... From what I know he had 
my 
port:qt5-kde installed, and then for some reason ran into a dependency when he 
tried to install port:kf5-kate that started pulling in the official port:qt5-
qtbase (and family), which created a conflict.

I don't know what dependency that was (he only ever provided the main.log for 
qt5-qtbase, which of course doesn't tell me why that port was installed). But 
he 
assured me that he followed the instructions and copied my Qt5 PortGroups into 
the main ports tree. That alone should have prevent this from happening.

He then reported the results of `port rdeps` without any ports installed (or 
active, I don't know). That indeed shows port:qt5-qtbase as a dependency of 
kf5-kate -> kf5-kinit -> kf5-kio -> kf5-knotifications -> phonon-qt5

I also know he's installing into a non-standard prefix and without using sudo 
at 
all, but that shouldn't really make any difference here.

The important thing here is that AFAIK he already had port:qt5-kde installed 
when he first ran into the conflict. That's the recommended way of installing 
my 
KF5 ports; port:qt5-kde is conceived to act as an alternative in the way -devel 
ports do (but with PortGroup support for rewriting depspecs that goes a bit 
beyond the usual path:-style depspecs). So even if there's indeed a pending 
issue with complex installs-from-scratch (assuming the deps tree is calculated 
only once) that was not the issue at hand according to my information.

This is the issue ticket:
https://github.com/RJVB/macstrop/issues/9

and the related https://trac.macports.org/ticket/54386 which I just filed 
(complete with proofreading failure in the subject :-/)

R.

Re: clean install simulation mode?

[Ryan Schmidt]

On Jun 27, 2017, at 03:39, René J.V. Bertin wrote:

> A user of my macstrop ports tree is reporting a conflict I cannot reproduce, 
> at least not without uninstalling or deactivating lots of ports that I need 
> to keep online.
> 
> Is there some way to get port to behave as if it needs to install everything, 
> or at least run the Portfiles of all dependencies so I can follow all 
> relevant diagnostic output? It's not perfectly clear to me if `port rdeps` 
> indeed does that.
> 
> To be more specific: I'd like to follow the propagation of a variant through 
> the dependency calculations via a print probe in a PortGroup. That variant is 
> set as a default_variant in said PortGroup and I have the impression it 
> doesn't propagate the same way a variant set by the user does.

I don't know if there's a way to make MacPorts do what you want.

Maybe if you describe the problem the user is experiencing, we can figure out 
why it's happening without needing to do what you're proposing.

Buildbot now fails to build wine dependencies

[Ryan Schmidt]

We used to be able to build wine on the buildbot, but we aren't anymore:

https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/32791

The error occurs when installing dependencies, specifically cairo:

> > Installing dependency (28 of 120) 'glib2' with variants '+universal+x11'
> ...
> --->  Deactivating glib2 @2.52.3_0+universal+x11
> ...

> > Installing dependency (55 of 120) 'cairo' with variants 
> '+quartz+universal+x11'
> ...
> Error: glib2: Variant quartz conflicts with x11

The cairo port has for years had both x11 and quartz variants that are both 
enabled by default. The glib2 port recently got x11 and quartz variants added, 
and they conflict with one another, as they do in most ports that have them; 
the user must choose one or the other. The default is x11, as it is for other 
ports that have this choice.

I think the problem is that mpbb is explicitly specifying the variants when 
installing the dependencies, particularly since wine is 32-bit so it needs the 
dependencies installed with the universal variant, and when installing cairo 
with x11, quartz and universal, it is passing those variants down to cairo's 
dependencies, including glib2.

I don't know why mpbb is specifying all the variants when building 
dependencies. It seems like it would be enough to just specify universal, and 
let the port's default variants take care of the rest.

Many years ago, cairo used to require the user to select whether to use x11 or 
quartz, but then it became possible to use both at once, and the variants were 
kept in case there turned out to be some situations where having both backends 
available caused some problem. As far as I know, no such problem was found, so 
I could just remove the variants from the cairo port, which would fix the 
problem for cairo, but would not fix it for all the other ports that have 
conflicting x11 and quartz variants and depend on glib2, and there are a couple 
of those:

$ port echo variant:quartz and variant:x11 and depends:glib2
cairo   
cairo-devel 
gtk3
librsvg 
libVLC  
pango   
pango-devel 
pidgin  
pspp
pspp-devel  
VLC 
webkit2-gtk 
webkit2-gtk-devel   

(Not all of these ports' x11 and quartz variants conflict.)

It's possible the problem only shows up when doing builds with non-default 
variants, which would only be universal at the moment.

clean install simulation mode?

[René J . V . Bertin]

Hi,

A user of my macstrop ports tree is reporting a conflict I cannot reproduce, at 
least not without uninstalling or deactivating lots of ports that I need to 
keep online.

Is there some way to get port to behave as if it needs to install everything, 
or at least run the Portfiles of all dependencies so I can follow all relevant 
diagnostic output? It's not perfectly clear to me if `port rdeps` indeed does 
that.

To be more specific: I'd like to follow the propagation of a variant through 
the dependency calculations via a print probe in a PortGroup. That variant is 
set as a default_variant in said PortGroup and I have the impression it doesn't 
propagate the same way a variant set by the user does.

Thanks,
R.