[GSoC] Announcing Google Summer of Code 2017 and Google Code-in 2016

[Jeremy Lavergne]

GSoC 2017 is announced!

Please add or refines ideas on the MacPorts wiki; anyone interested in
mentoring is encouraged to contact those of us regularly involved with
the program (the likely administrators):
 * s...@macports.org (myself)
 * c...@macports.org (Clemens)
 * rai...@macports.org (Rainer)


 Forwarded Message 
Subject:[GSoC Mentors] Announcing Google Summer of Code 2017 and
Google Code-in 2016
Date:   Mon, 10 Oct 2016 10:11:19 -0700 (PDT)
Reply-To:   sttaylor 



Hello all,


We are pleased to announce Google Summer of Code 2017
, the 13th straight year of the program.


The GSoC 2017 timeline has been updated with next year's important
dates. More information including some changes to the Program Rules will
be updated in early November on the program site .


Organizations -- If you would like to apply for the 2017 program please
start thinking about the projects you would like students to work on and
also reach out to your community members to ask if they would like to be
mentors for the program.

We are looking forward to another exciting year of GSoC!


Today we also announced the Google Code-in 2016 contest
that will be open for past GSoC mentoring organizations to apply to be a
part of this exciting 7 week contest bringing teenagers into the open
source community. Organization applications are open for GCI from
October 24th - November 7th.  GCI opens for student participants on
November 28th!


For any questions about the programs please email us at
gsoc-supp...@google.com


Best,

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

Re: Documentation overhaul

[Ryan Schmidt]

> On Oct 10, 2016, at 2:44 PM, Rainer Müller  wrote:
> 
> On 2016-10-10 01:23, Ryan Schmidt wrote:
>> Thanks for your interest, Marcel, but do you feel you would be able
>> to lead such an effort, since you seem to be new to MacPorts? I've
>> been with MacPorts for around 10 years and have thought of rewriting
>> the documentation for several years so I feel I might be able to do
>> it. I'm just not doing it right this second because I'm busy trying
>> to move us to new hosting. And also because we don't yet know how how
>> we will work on GitHub, so we can't fully document that yet.
> 
> Our documentation has been in a dire state for years now. As I mentioned
> before, the new help system was started by me about 7 years ago. Even
> back then we were already discussing to convert/rewrite the guide. Not
> much has changed since then.
> 
> Most of the time the man page project was in limbo because nobody was
> writing the actual man pages. I also lost motivation after a while and
> eventually Clemens picked it up and finished it.
> 
> Now here is Marcel offering his help with the documentation. I do not
> want to turn down his offer or stop him from contributing in any way.
> 
> I do not think a lot of experience is required to write good
> documentation. Especially when we are talking about reorganizing the
> existing documents. Being only a user could help to write the
> documentation from the view of a user without diving too deep into
> internals.
> 
> Moving away from Docbook, converting the existing content or evaluating
> other tools would be a lot of work that could be done by anyone.

Note that the docbook xsl can be automatically converted to asciidoc or other 
formats using pandoc; that's what I used for a quick test.

In the guide directory, run this script:


#!/bin/bash

OUTPUT_FMT=asciidoc
OUTPUT_EXT=asciidoc
OUTPUT_DIR=asciidoc

mkdir -p $OUTPUT_DIR
find xml -name '*.xml' | xargs -n 1 -I % sh -c "CMD="\""pandoc --from docbook 
--to $OUTPUT_FMT --standalone --output=\$(echo % | sed -E 
's,xml/(.*)\.xml,$OUTPUT_DIR/\1.$OUTPUT_EXT,') %"\"" && echo \$CMD && \$CMD"


But manual cleanup will probably be required.


>> My plan is to read all documentation, maybe even print it all out on
>> paper (guide, wiki, web site), cut it up, group related information
>> together, remove duplication (like the three different sets of
>> install documentation we currently have), remove superfluous
>> language, simplify, and also add new documentation for things that
>> currently aren't documented, like newer portgroups. Also review the
>> organization and content of the documentation of other projects that
>> I consider well done, such as svnbook.org. If you know of other good
>> documentation I should review let me know.
> 
> One of the most important steps would be to split the documentation
> clearly into:
> 
> * Installation
> + MacPorts Quickstart/Cheat Sheet
> * Using MacPorts
> * Writing Portfiles
> * Contributing
> + List of Terms/Glossary
> * Management Policies
> * Internals for base Developers
> 
>  * = already exists
>  + = needs to be written
> 
> Overall:
> make it more concise, less text, examples instead of explanations.
> 
> Maybe split installation instructions by macOS versions so users only
> see relevant instructions.

Yes, I did this for the "new web site" I built a few years back, and intend to 
use that strategy on whatever new web site we end up with. I intend for this to 
be on the web site, not in the guide. The guide can contain alternate 
installation instructions, like building from source.

Or, if we prefer, all installation instructions, even dmg/pkg installation 
instructions, by OS version, can be in the guide, and the web site can be 
reduced to just providing links to the downloads and to the installation 
instructions. That could be fine, and I do like the idea of having all 
documentation together in one place. In my previous "new web site", I used 
include files and if/then logic so that any given text only had to be written 
once. There is overlap in installation instructions for different OS versions, 
and I would not want to have to manually keep that content synchronized between 
multiple OS versions. I didn't know whether asciidoc supported include files or 
conditional logic.


> It would also be good to have some conditionals to mark
> paragraphs/sections by version. Then we could write documentation for
> trunk while the website keeps displaying the stable versions (or let you
> choose).
> 
> To me, svnbook.org is old, outdated and the HTML version on the web
> definitely does not feel modern.

I'm not referring at all to the presentation of the svnbook.org site. I intend 
to use Twitter Bootstrap for CSS styling across the new web presence.

Rather, I was referring to the content of the book, which I consider to be very 
well written and well organized, and I'm seeking other examples of well written 
and well organized project documentation. 

Re: gcr requires gtk to be installed with +x11

[Ryan Schmidt]

On Oct 10, 2016, at 15:23, Johannes Kastl  wrote:
> 
>> On 10.10.16 22:20 David Evans wrote:
>> 
>> Yesterday. r153733 removed the run time dependency on epiphany from gimp2.
>> Perhaps you need to update your ports?
>> 
>> sudo port selfupdate
> 
> I did, but maybe I got a stale mirror. Anyway, I'll try again.

You get whatever mirror you have specified in your macports.conf file. The 
Seattle mirror is stale; the others update several times a day. 


>> Yes, this is over kill but it makes sure that you don't have
>> any spurious +x11 dependencies of epiphany laying around to bite you.
> 
> Should I not activate them again after that?

Johannes, you should re-activate any other ports you actually want to use. 

Dave, telling people to deactivate all active ports to fix a gimp issue is 
probably not ideal, because although it may fix the gimp issue, it will also 
deactivate any other ports the user was using. At least, not without explaining 
that to the user.

Johannes, the reason for Dave's suggestion is that you really need to make the 
choice about whether to use x11 or quartz before you have installed any ports. 
Trying to change that decision after you have already installed ports will lead 
to problems. This situation is somewhat muddled by the fact that some ports 
(like cairo) can be installed with both variants simultaneously, and that a few 
ports (currently only VLC, VLC-devel and libVLC, I think) default to quartz 
instead of x11. More problematic is that not all ports that support x11 also 
support quartz, so even if you decided you want to use quartz, you may find you 
want to install a port that only works with x11, and trying to do so will cause 
problems. 

See the thread going on now on the macports-users list for more on this 
situation. 



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

Re: Documentation overhaul

[Clemens Lang]

Hi,

On Mon, Oct 10, 2016 at 09:44:17PM +0200, Rainer Müller wrote:
> Now here is Marcel offering his help with the documentation. I do not
> want to turn down his offer or stop him from contributing in any way.
> 
> [...]
>
> If Marcel has time right now, I think he should just start with the
> documentation.

I fully agree. Marcel, since I've touched most of our documentation at
some point (even though only for minor changes), feel free to reach out
to me if you have any questions. I likely won't have a lot of time to
contribute text on my own, but I can certainly point you to existing
documentation or clarify behavior that isn't documented yet.

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

Re: gcr requires gtk to be installed with +x11

[David Evans]

On 10/10/16 1:23 PM, Johannes Kastl wrote:
> On 10.10.16 22:20 David Evans wrote:
> 
>> Yesterday. r153733 removed the run time dependency on epiphany from gimp2.
>> Perhaps you need to update your ports?
>>
>> sudo port selfupdate
> 
> I did, but maybe I got a stale mirror. Anyway, I'll try again.
> 
>> Yes, this is over kill but it makes sure that you don't have
>> any spurious +x11 dependencies of epiphany laying around to bite you.
> 
> Should I not activate them again after that?

No need to if you don't need them for something else and you probably
don't because you're using +quartz ports exclusively.  The point is to
get rid of anything that requires +x11 to build.
> 
>> No problem.  I'm just not communicating well today.
> 
> Happens to all of us. Sometimes. ;-)

Indeed.

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

Re: gcr requires gtk to be installed with +x11

[Johannes Kastl]

On 10.10.16 22:20 David Evans wrote:

> Yesterday. r153733 removed the run time dependency on epiphany from gimp2.
> Perhaps you need to update your ports?
> 
> sudo port selfupdate

I did, but maybe I got a stale mirror. Anyway, I'll try again.

> Yes, this is over kill but it makes sure that you don't have
> any spurious +x11 dependencies of epiphany laying around to bite you.

Should I not activate them again after that?

> No problem.  I'm just not communicating well today.

Happens to all of us. Sometimes. ;-)

Johannes



signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: gcr requires gtk to be installed with +x11

[David Evans]

On 10/10/16 12:58 PM, Johannes Kastl wrote:
> On 10.10.16 21:51 David Evans wrote:
> 
>> Because gcr requires +x11 and you had gtk3 +quartz installed for
>> gimp2 +quartz
> 
> I figured this much. But why was it suddenly listed as a dependency
> for gimp2+quartz?
> 
>> Why?  gcr is a dependency of epiphany but not (now) of gimp2.
>> gimp2 no longer depends on epiphany so it doesn't depend on gcr
>> either.  Just ignore gcr.
> 
> When did this change? I tried earlier today and had no chance...

Yesterday. r153733 removed the run time dependency on epiphany from gimp2.
Perhaps you need to update your ports?

sudo port selfupdate

> 
>> Try this (to deactivate any conflicting +x11 ports that were
>> dependencies of epiphany)
> 
>> sudo port deactivate active 
>> sudo port install gimp2 +quartz
> 
>> Works for me.
> 
> JFTR, the first line deactivates all active ports? huh?
Yes, this is over kill but it makes sure that you don't have
any spurious +x11 dependencies of epiphany laying around to bite you.

For instance gnome-desktop is another dependency of epiphany that
requires +x11.  In fact, it's what brought gcr in.

epiphany -> gnome-desktop -> gcr

But you could do this instead, I guess.

sudo port deactivate rdepof:epiphany and active
sudo port install gimp2 +x11

Anyway no need to install gtk3 +x11 unless you really want to for
other reasons (and it will conflict with gimp2 +quartz of course)

> 
> Johannes
> 
> P.S.: Thanks for your help!

No problem.  I'm just not communicating well today.

Best, Dave


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

Re: gcr requires gtk to be installed with +x11

[David Evans]

On 10/10/16 10:58 AM, Johannes Kastl wrote:
> On 09.10.16 10:24 Johannes Kastl wrote:
> 
>>> --->  Computing dependencies for gcr --->  Fetching archive
>>> for gcr Error: org.macports.archivefetch for port gcr returned:
>>> gtk3 must be installed with +x11.
> 
> I still get the same error, so I guess it has not been a temporary
> failure.
> 
> Is there a way to get gimp2+quartz to build without having to
> install all of x11?
> 
> And: Why has this changed suddenly? What made gimp2 require gcr? Or
> what made gcr require gtk3+x11 as dependency?

Again, mea culpa.  I added epiphany as a dependency for gimp2.  I removed
that dependency because epiphany doesn't build +quartz, just +x11.

gcr is a dependency of epiphany and it too only builds +x11.  But you don't
need it any more because gimp2 no longer depends on epiphany.  So get rid of
it and don't try to build it.

A clean build of gimp2 +quartz and its dependencies builds and works fine for
me.  As I recommended before, to do a clean build of gimp2 without problems
from any spurious +x11 ports that are lying around, do this:

sudo port deactivate active
sudo port install gimp2 +quartz

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

Re: gcr requires gtk to be installed with +x11

[Johannes Kastl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10.10.16 21:51 David Evans wrote:

> Because gcr requires +x11 and you had gtk3 +quartz installed for
> gimp2 +quartz

I figured this much. But why was it suddenly listed as a dependency
for gimp2+quartz?

> Why?  gcr is a dependency of epiphany but not (now) of gimp2.
> gimp2 no longer depends on epiphany so it doesn't depend on gcr
> either.  Just ignore gcr.

When did this change? I tried earlier today and had no chance...

> Try this (to deactivate any conflicting +x11 ports that were
> dependencies of epiphany)
> 
> sudo port deactivate active sudo port install gimp2 +quartz
> 
> Works for me.

JFTR, the first line deactivates all active ports? huh?

Johannes

P.S.: Thanks for your help!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlf78tkACgkQzi3gQ/xETbIqIwCeKDi6HhaGL86Dq8ABNJdKAYf7
H/kAn2G73LRgpuqAkM7q11chCPnwyZAR
=7JlI
-END PGP SIGNATURE-

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

Re: gcr requires gtk to be installed with +x11

[David Evans]

On 10/9/16 1:24 AM, Johannes Kastl wrote:
> Hi David,
> 
> thanks for the help.
> 
> On 09.10.16 07:50 David Evans wrote:
> 
>> I've confirmed that gcr's dependency on gnupg is unnecessary --
>> works fine without it.  Removed in r153722. Let me know if you
>> have any further problems upgrading gimp2.
> 
> I tried to install gcr to confirm that it does no longer conflict
> with gnupg21. But I could not.

Because gcr requires +x11 and you had gtk3 +quartz installed for gimp2 +quartz

> 
> I had gimp2 installed with +quartz variant, thus gtk3 is being built
> with +quartz. Now gcr tells me:
> 
>> --->  Computing dependencies for gcr --->  Fetching archive for
>> gcr Error: org.macports.archivefetch for port gcr returned: gtk3
>> must be installed with +x11.

Because gcr requires +x11 and you had gtk3 +quartz installed for gimp2 +quartz
> 
> I'll try to install gtk3 with +x11, and see what happens, but I
> guess then I can't install gimp2 with +quartz...

Why?  gcr is a dependency of epiphany but not (now) of gimp2.  gimp2 no longer
depends on epiphany so it doesn't depend on gcr either.  Just ignore gcr.

Try this (to deactivate any conflicting +x11 ports that were dependencies of 
epiphany)

sudo port deactivate active
sudo port install gimp2 +quartz

Works for me.

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

Re: Documentation overhaul

[Rainer Müller]

On 2016-10-10 01:23, Ryan Schmidt wrote:
> Thanks for your interest, Marcel, but do you feel you would be able
> to lead such an effort, since you seem to be new to MacPorts? I've
> been with MacPorts for around 10 years and have thought of rewriting
> the documentation for several years so I feel I might be able to do
> it. I'm just not doing it right this second because I'm busy trying
> to move us to new hosting. And also because we don't yet know how how
> we will work on GitHub, so we can't fully document that yet.

Our documentation has been in a dire state for years now. As I mentioned
before, the new help system was started by me about 7 years ago. Even
back then we were already discussing to convert/rewrite the guide. Not
much has changed since then.

Most of the time the man page project was in limbo because nobody was
writing the actual man pages. I also lost motivation after a while and
eventually Clemens picked it up and finished it.

Now here is Marcel offering his help with the documentation. I do not
want to turn down his offer or stop him from contributing in any way.

I do not think a lot of experience is required to write good
documentation. Especially when we are talking about reorganizing the
existing documents. Being only a user could help to write the
documentation from the view of a user without diving too deep into
internals.

Moving away from Docbook, converting the existing content or evaluating
other tools would be a lot of work that could be done by anyone.

> My plan is to read all documentation, maybe even print it all out on
> paper (guide, wiki, web site), cut it up, group related information
> together, remove duplication (like the three different sets of
> install documentation we currently have), remove superfluous
> language, simplify, and also add new documentation for things that
> currently aren't documented, like newer portgroups. Also review the
> organization and content of the documentation of other projects that
> I consider well done, such as svnbook.org. If you know of other good
> documentation I should review let me know.

One of the most important steps would be to split the documentation
clearly into:

* Installation
+ MacPorts Quickstart/Cheat Sheet
* Using MacPorts
* Writing Portfiles
* Contributing
+ List of Terms/Glossary
* Management Policies
* Internals for base Developers

  * = already exists
  + = needs to be written

Overall:
make it more concise, less text, examples instead of explanations.

Maybe split installation instructions by macOS versions so users only
see relevant instructions.

It would also be good to have some conditionals to mark
paragraphs/sections by version. Then we could write documentation for
trunk while the website keeps displaying the stable versions (or let you
choose).

To me, svnbook.org is old, outdated and the HTML version on the web
definitely does not feel modern.

> My plan is to do this after redoing the web site. I intend to keep
> the installation instructions that have to do with the default
> installation using the macOS Installer on the web site, so rewriting
> that will be a good beginning to rewriting the documentation.

I know you have been working on the new website for quite a while. But
you also do the buildbot and other management related tasks. I would
even say chances are high that this will be delayed further...

If Marcel has time right now, I think he should just start with the
documentation.

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

Re: gcr requires gtk to be installed with +x11

[Johannes Kastl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10.10.16 19:58 Johannes Kastl wrote:

> Is there a way to get gimp2+quartz to build without having to 
> install all of x11?

I had to install pango, cairo and gdk-pixbuf2 with +x11. Then I
could install "gtk3 +x11 -quartz" and gcr without errors. gimp2 is
still building, so I guess it is ok.

> And: Why has this changed suddenly? What made gimp2 require gcr?
> Or what made gcr require gtk3+x11 as dependency?

I guess it might be my variants.conf, which sets "+quartz". So gtk3
(which was not used before?) got built with the wrong variant.

Strange. And stupid, somehow. But at least it seems to be working now.
..

Johannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlf75vIACgkQzi3gQ/xETbKB2ACeN5s+A0bUydzyzytEPDQ05NBP
QwcAoJDG/TSiKz5m3LY73l0xaI3/u/42
=KD84
-END PGP SIGNATURE-

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

Ticket review request

[Sterling Smith]

MacPorts Committers,

Please review/test/commit https://trac.macports.org/ticket/47941.

Thanks,
Sterling

PS Looking forward to GitHub Pull Requests...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: gcr requires gtk to be installed with +x11

[Johannes Kastl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09.10.16 10:24 Johannes Kastl wrote:

>> --->  Computing dependencies for gcr --->  Fetching archive
>> for gcr Error: org.macports.archivefetch for port gcr returned:
>> gtk3 must be installed with +x11.

I still get the same error, so I guess it has not been a temporary
failure.

Is there a way to get gimp2+quartz to build without having to
install all of x11?

And: Why has this changed suddenly? What made gimp2 require gcr? Or
what made gcr require gtk3+x11 as dependency?

Thanks in advance.

Johannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlf71toACgkQzi3gQ/xETbJcoACfUPmZyn5UnlX0ILxPvyPAFdLG
+GcAn30ZtOepm3SJnFWk3jQgDdpAThYr
=1eGk
-END PGP SIGNATURE-

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

Re: reasons for `port provides` not working?

[Joshua Root]

On 2016-10-11 03:05 , René J.V. Bertin wrote:

Is there a good reason why action_provides (in port) does a `file normalize`?




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

Re: reasons for `port provides` not working?

[René J . V . Bertin]

On Monday October 10 2016 18:05:19 René J.V. Bertin wrote:

>Is there a good reason why action_provides (in port) does a `file normalize`?

Actually, doing that must make it impossible to trace which port installs a 
given symlink. While it can be interesting to know to whom the target belongs, 
that's not always the question (on the contrary, I'd say).

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

Re: reasons for `port provides` not working?

[Rainer Müller]

On 2016-10-10 18:05, René J.V. Bertin wrote:
> Is there a good reason why action_provides (in port) does a `file normalize`? 
> Wouldn't it be just as OK if the actual registry lookup (after doing all 
> checks) used the original $filename?

file normalize is used to support relative paths and paths containing
"../" components.

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

Re: reasons for `port provides` not working?

[René J . V . Bertin]

On Monday October 10 2016 17:29:18 Clemens Lang wrote:

> > In fact, in absence of proof that my use of a symlinked $prefix explains
> > everything I won't assume that that is the culprit.
> 
> Well, let me lawyer you with your own mail from 2014 then:
>   https://lists.macosforge.org/pipermail/macports-users/2014-July/035965.html
> Your attitude of "unless you can proof it's me, it's you" isn't helpful. I've
> had enough of it.

Pardon, exactly where do I say that "it's you" (except maybe between the lines 
in that old exchange)?

And you think that telling me that it's the fact I'm doing something that's not 
supported is helpful or maybe even educational? I'm not unwilling to accept 
that my working hypothesis is wrong, but for that I'll need to know why the 
lookup fails in one condition but not in another.

In fact, I just discovered the reason. It is indeed related to my using a 
symlinked prefix. See? I wasn't right, but also not entirely wrong because I 
got the feature to work without reinstalling. I'll even admit to having been 
extremely shortsighted not registering the "offending" operation immediately.

Is there a good reason why action_provides (in port) does a `file normalize`? 
Wouldn't it be just as OK if the actual registry lookup (after doing all 
checks) used the original $filename?

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

Re: reasons for `port provides` not working?

[Rainer Müller]

On 2016-10-10 16:49, René J.V. Bertin wrote:
> On Monday October 10 2016 15:30:57 Clemens Lang wrote:
>> IIRC the problem was that your installation mangled paths somehow, either by
>> making /opt/local a symlink or some other uncommon configuration.
> 
> Yes (/opt/local is a symlink), but from what I read on here that is not 
> *that* uncommon and that it's been getting silent support in practice.

What kind of setup is this?
1) /opt/local is the prefix, but the directory was moved and replaced
   with a symlink
2) you installed into a different prefix and then added a symlink at
   /opt/local

> Either way, this shouldn't have any incidence on file-to-port lookups.
> Either:
> - /opt/local/foo/bar is registered as such and a look-up of that path succeeds
> - /opt/local/foo/bar is actually /what/ever/foo/bar, registered as such, and 
> thus a look-up of the resolved path succeeds.
> 
> Neither look-ups work via `port provides` (i.e. via 
> registry::file_registered) but one of them clearly does via [registry::entry 
> owner] (in portimage.tcl::activate_contents). 

Which one does work? What does 'port contents' return?

You could also look into the registry manually to find out which path
was registered. Instructions are here:

https://trac.macports.org/browser/trunk/base/src/cregistry/README.sqlext

For example:
SELECT * FROM files WHERE id = (SELECT id FROM ports WHERE name = 'zlib'
AND state = 'installed');

Note: state 'installed' corresponds to the pseudo-port active, while the
pseudo-port installed would be 'imaged'. Historical reasons.

>> You'll forgive me when I just tell you that problems caused by unsupported
>> modifications made by you locally are not supported by MacPorts. I won't 
>> spend
>> any time diagnosing this unless you can show that it's broken in a fresh
>> install.
> 
> Good thing I didn't ask you specifically then... 
> 
> In fact, in absence of proof that my use of a symlinked $prefix explains 
> everything I won't assume that that is the culprit. I'm more inclined to 
> believe that it is the rescue operation I've had to do a year or 2,3 back 
> because an upgrade (2.3.3 -> 2.3.4 IIRC) had not run all required steps. As 
> far as I can remember `port provides` worked perfectly fine in 2.3.3 - and 
> I've always had a symlinked $prefix.

The general rule is that if you run a non-standard installation, you
will have to debug that yourself, because it is complicated to reproduce
your issue for anyone else.

If your last upgrade was not complete, it is usually safe to just re-run
the installation on top of the existing prefix.

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

Re: reasons for `port provides` not working?

[Clemens Lang]

Hi,

- On 10 Oct, 2016, at 16:49, René J.V. Bertin rjvber...@gmail.com wrote:

> Either way, this shouldn't have any incidence on file-to-port lookups.
> Either:
> - /opt/local/foo/bar is registered as such and a look-up of that path succeeds
> - /opt/local/foo/bar is actually /what/ever/foo/bar, registered as such, and
> thus a look-up of the resolved path succeeds.

It's debatable whether it shouldn't. It does.


> Good thing I didn't ask you specifically then...

You're asking the list, and I'm sure others may have the same impression.


> In fact, in absence of proof that my use of a symlinked $prefix explains
> everything I won't assume that that is the culprit.

Well, let me lawyer you with your own mail from 2014 then:
  https://lists.macosforge.org/pipermail/macports-users/2014-July/035965.html
Your attitude of "unless you can proof it's me, it's you" isn't helpful. I've
had enough of it.

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

Re: reasons for `port provides` not working?

[René J . V . Bertin]

On Monday October 10 2016 15:30:57 Clemens Lang wrote:

Hi,

> IIRC the problem was that your installation mangled paths somehow, either by
> making /opt/local a symlink or some other uncommon configuration.

Yes (/opt/local is a symlink), but from what I read on here that is not *that* 
uncommon and that it's been getting silent support in practice.

Either way, this shouldn't have any incidence on file-to-port lookups.
Either:
- /opt/local/foo/bar is registered as such and a look-up of that path succeeds
- /opt/local/foo/bar is actually /what/ever/foo/bar, registered as such, and 
thus a look-up of the resolved path succeeds.

Neither look-ups work via `port provides` (i.e. via registry::file_registered) 
but one of them clearly does via [registry::entry owner] (in 
portimage.tcl::activate_contents). 

> You'll forgive me when I just tell you that problems caused by unsupported
> modifications made by you locally are not supported by MacPorts. I won't spend
> any time diagnosing this unless you can show that it's broken in a fresh
> install.

Good thing I didn't ask you specifically then... 

In fact, in absence of proof that my use of a symlinked $prefix explains 
everything I won't assume that that is the culprit. I'm more inclined to 
believe that it is the rescue operation I've had to do a year or 2,3 back 
because an upgrade (2.3.3 -> 2.3.4 IIRC) had not run all required steps. As far 
as I can remember `port provides` worked perfectly fine in 2.3.3 - and I've 
always had a symlinked $prefix.

Does `port contents` return the result of the reverse lookup? This feature 
works, and could be used to create a very slow version of `port provides`.

What kind of sqlite expression (evaluated directly in/on the registry db) would 
normally return the expected information? Is there a ditto command that returns 
all full paths matching just a filename?

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

Re: reasons for `port provides` not working?

[Clemens Lang]

Hi,

- On 10 Oct, 2016, at 15:11, René J.V. Bertin rjvber...@gmail.com wrote:

> I've been bitten once too often by an oversight that I c/should have seen if
> `port provides` worked. It's not been working for me for a long time, and
> mostly I don't really miss it, but now I'd like to figure out if there's a way
> to get this feature online again.
> 
> Without reinstalling from scratch, of course.
> 
> What could this be related to?

IIRC the problem was that your installation mangled paths somehow, either by
making /opt/local a symlink or some other uncommon configuration.

> FWIW, I do get a proper error when a port tries to install a file already
> installed by another file, so a priori the information is all there.

You'll forgive me when I just tell you that problems caused by unsupported
modifications made by you locally are not supported by MacPorts. I won't spend
any time diagnosing this unless you can show that it's broken in a fresh
install.

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

reasons for `port provides` not working?

[René J . V . Bertin]

Hi,

I've been bitten once too often by an oversight that I c/should have seen if 
`port provides` worked. It's not been working for me for a long time, and 
mostly I don't really miss it, but now I'd like to figure out if there's a way 
to get this feature online again.

Without reinstalling from scratch, of course.

What could this be related to?

The crazy thing is that it works perfectly on my "LinuxPorts" install which 
isn't even supposed to exist ;)

FWIW, I do get a proper error when a port tries to install a file already 
installed by another file, so a priori the information is all there.

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

Re: 2nd MacPorts Meeting & Online Meeting

[Aljaž Srebrnič]

> On 10 ott 2016, at 07:53, Mojca Miklavec  wrote:
> 
> Hi,
> 
> Me and Aljaž would be willing to host the MacPorts meeting in 2017 again.
> 
> If you have any particular requests about the desired time / place /
> or anything else, we can discuss it before we fix the dates, but we
> should probably fix it some time soon.

I *may* have a place, we could meet at Mittelab’s new “home”, we have a B 
chain hotel *literally* on the other side of the road, and a bigger and nicer 
space to hack/discuss. As for the time, I think March would be good.


> 
> 
> In addition to the face-to-face meeting, I would like to propose
> trying out some online meeting some time in mid-November (or any other
> time, according to your wishes). I would propose to discuss:
> 
> - creating timeline(s) with most important features that we might want
> to implement & get into next releases
> 
> - how to improve the ticket system
> 
> - and/or any other pressing topic (just not too much all at once)
> 
> I'm not sure about the best format of the online meeting though
> (IRC?). Any suggestions welcome. It would be nice to prepare proposals
> / agenda for discussion in advance though. I would limit the meeting
> to 2 hours max and repeat it if necessary.

Yes, that makes sense for me. Discussing on IRC is going to be a pain, though. 
Maybe a video conference using Google Hangouts?

--
Aljaž Srebrnič a.k.a g5pw
My public key:  https://g5pw.me/key
Key fingerprint = 2109 8131 60CA 01AF 75EC  01BF E140 E1EE A54E E677


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