Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[René J . V . Bertin]

On Wednesday October 26 2016 00:25:14 Clemens Lang wrote:

Hi,

> The problem is that we don't see the difference. The code that procudes
> the error is more or less
>   "source $filename"
> which can fail either because the file isn't there, or because the code
> in the file failed.

Yeah. There could be a check if the Portfile exists to catch the 1st 
possibility, and some more information about the error (if there was one) could 
be useful too; the catch command can return a string with that information.

> > PortGroup from the same directory as the main PortGroup, and that
> > condition cannot hold for copies in the registry which all live in
> > their own directory.
> 
> So the behavior was actually correct.

Yes. In fact, after fixing the offending code in my stuff I spent at least half 
an hour trying to figure which of the other recent modifications to my stuff 
could explain the error I ended up reporting.

Has anyone been able to confirm this issue? For example:

- port -n install foo configure.optflags="-Os -g"
- port -nkvd upgrade --force foo configure.optflags="-Os -g"

> Additional files are not saved alongside the port. You should probably
> avoid depending on external files for the pre- and post-deactivate
> phases and running the Portfile.

Or doing anything with them in the shared parts of the Portfile...

> We could argue that's a bug, but this has worked quite fell so far.

As long as it doesn't make it impossible to do something that's absolutely 
necessary, it's not a bug but just as shortcoming ;)


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

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[Clemens Lang]

Hi,

On Wed, Oct 26, 2016 at 12:29:10AM +0200, René J.V. Bertin wrote:
> The issue I mentioned that I fixed was such an example of an
> oversight. I'd imposed the condition of reading a "companion"
> PortGroup from the same directory as the main PortGroup, and that
> condition cannot hold for copies in the registry which all live in
> their own directory.

So the behavior was actually correct.


> But the configure.optflags issue is not due to an issue in a Portfile
> or PortGroup. As far as I can tell it happens with every port; it just
> goes unnoticed because most of the time people (presumably) don't
> specify additional compiler flags.

While the possiblity to set these flags on the command line exists, this
is for development purposes only and unsupported. If you have a patch to
fix this, I'm happy to apply it.


> BTW: what is ${filespath} set to for ports executed from the registry?
> If it doesn't point to the usual location there's probably room for a
> mechanism to specify additional files to store in the registry port
> dir.

Additional files are not saved alongside the port. You should probably
avoid depending on external files for the pre- and post-deactivate
phases and running the Portfile.

We could argue that's a bug, but this has worked quite fell so far.

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

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

[Lawrence Velázquez]

> On Oct 25, 2016, at 4:43 PM, René J.V. Bertin  wrote:
> 
> Where does one file tickets for trac?

In Trac.

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

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[René J . V . Bertin]

On Tuesday October 25 2016 17:06:27 Ryan Schmidt wrote:

Hi,

> > As such, Portfiles or PortGroups that haven't been written carefully can
> > trigger this warning from time to time. A common problem is checking for
> > the presence of a file, or running a tool, and not catching the errors.
> 
> Ah. So the error message is just wrong? There isn't actually a problem 
> opening the portfile from the registry; there's a problem running the 
> portfile that was successfully opened and read?

Insofar as you can distinquish between reading, parsing and running the 
portfile, yes. The issue I mentioned that I fixed was such an example of an 
oversight. I'd imposed the condition of reading a "companion" PortGroup from 
the same directory as the main PortGroup, and that condition cannot hold for 
copies in the registry which all live in their own directory.

But the configure.optflags issue is not due to an issue in a Portfile or 
PortGroup. As far as I can tell it happens with every port; it just goes 
unnoticed because most of the time people (presumably) don't specify additional 
compiler flags.

BTW: what is ${filespath} set to for ports executed from the registry? If it 
doesn't point to the usual location there's probably room for a mechanism to 
specify additional files to store in the registry port dir.

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

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[Clemens Lang]

Hi,

On Tue, Oct 25, 2016 at 05:06:27PM -0500, Ryan Schmidt wrote:
> Ah. So the error message is just wrong? There isn't actually a problem
> opening the portfile from the registry; there's a problem running the
> portfile that was successfully opened and read?

Yes, unless of course you randomly deleted files in the path where
MacPorts keeps those historic copies of Portfiles, or there's a bug in
the code that maintains these files.

The problem is that we don't see the difference. The code that procudes
the error is more or less
  "source $filename"
which can fail either because the file isn't there, or because the code
in the file failed.

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

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[Ryan Schmidt]

> On Oct 25, 2016, at 5:04 PM, Clemens Lang  wrote:
> 
> Hi,
> 
> On Tue, Oct 25, 2016 at 08:34:31AM -0500, Ryan Schmidt wrote:
>> I don't know the answers to your questions, but I wanted to mention
>> that I also have noticed the "Failed to open portfile from registry"
>> error far more often than seems normal to me. ("Never" would seem
>> normal to me.)
> 
> Interesting. The last time I've seen any of these messages is for the
> last GHC upgrade, and they were indeed expected and could not be avoided
> there.
> 
> On Tue, Oct 25, 2016 at 07:17:23PM +0200, René J.V. Bertin wrote:
>> Yes, never would seem normal, esp. if the Portfile is there when you
>> check :)
> 
> When a port is opened from registry, it does not use the state of the
> Portfile that you currently have in your ports tree. It uses the state
> of the Portfile as it was when you installed the port. This also applies
> to PortGroups.
> 
> As such, Portfiles or PortGroups that haven't been written carefully can
> trigger this warning from time to time. A common problem is checking for
> the presence of a file, or running a tool, and not catching the errors.

Ah. So the error message is just wrong? There isn't actually a problem opening 
the portfile from the registry; there's a problem running the portfile that was 
successfully opened and read?

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

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[Clemens Lang]

Hi,

On Tue, Oct 25, 2016 at 08:34:31AM -0500, Ryan Schmidt wrote:
> I don't know the answers to your questions, but I wanted to mention
> that I also have noticed the "Failed to open portfile from registry"
> error far more often than seems normal to me. ("Never" would seem
> normal to me.)

Interesting. The last time I've seen any of these messages is for the
last GHC upgrade, and they were indeed expected and could not be avoided
there.

On Tue, Oct 25, 2016 at 07:17:23PM +0200, René J.V. Bertin wrote:
> Yes, never would seem normal, esp. if the Portfile is there when you
> check :)

When a port is opened from registry, it does not use the state of the
Portfile that you currently have in your ports tree. It uses the state
of the Portfile as it was when you installed the port. This also applies
to PortGroups.

As such, Portfiles or PortGroups that haven't been written carefully can
trigger this warning from time to time. A common problem is checking for
the presence of a file, or running a tool, and not catching the errors.

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

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

[René J . V . Bertin]

On Sunday October 23 2016 17:43:56 Clemens Lang wrote:

> top bar. If you think those should be larger, feel free to suggest a
> patch to https://github.com/macports/trac.macports.org/.

Well, I'm not a web coder, so I'd prefer to file request tickets somewhere. 
Also for the fact that nowadays I get 2 emails when I replace an attachment 
with a newer version.
Where does one file tickets for trac?

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

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[Lawrence Velázquez]

> On Oct 25, 2016, at 1:17 PM, René J.V. Bertin  wrote:
> 
> I've looked into putting the offending statement (`$workername eval set 
> user_options($opt) $val`) in a loop, something like
> 
> $workername eval set user_options($opt) ""
> foreach v $val {
>$workername eval set user_options($opt) "$user_options($opt) $v"
> }
> 
> but I haven't gotten that right yet.

I haven't looked at the offending code, but I can tell you that this
approach is inherently flawed and cannot work robustly. The issue is
unwanted double substitution; the solution must prevent this, not work
around it.

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

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[Ryan Schmidt]

> On Oct 25, 2016, at 12:17 PM, René J.V. Bertin  wrote:
> 
> On Tuesday October 25 2016 08:34:31 Ryan Schmidt wrote:
> 
>> I don't know the answers to your questions, but I wanted to mention that I 
>> also have noticed the "Failed to open portfile from registry" error far more 
>> often than seems normal to me. ("Never" would seem normal to me.)
> 
> Yes, never would seem normal, esp. if the Portfile is there when you check :)
> 
> Are you running base from SVN?

Yes, trying to keep it updated every so often.


> I've looked into putting the offending statement (`$workername eval set 
> user_options($opt) $val`) in a loop, something like
> 
> $workername eval set user_options($opt) ""
> foreach v $val {
>$workername eval set user_options($opt) "$user_options($opt) $v"
> }
> 
> but I haven't gotten that right yet.
> 
> R.

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

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[René J . V . Bertin]

On Tuesday October 25 2016 08:34:31 Ryan Schmidt wrote:

>I don't know the answers to your questions, but I wanted to mention that I 
>also have noticed the "Failed to open portfile from registry" error far more 
>often than seems normal to me. ("Never" would seem normal to me.)

Yes, never would seem normal, esp. if the Portfile is there when you check :)

Are you running base from SVN?

I've looked into putting the offending statement (`$workername eval set 
user_options($opt) $val`) in a loop, something like

$workername eval set user_options($opt) ""
foreach v $val {
$workername eval set user_options($opt) "$user_options($opt) $v"
}

but I haven't gotten that right yet.

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

Re: Trac & Subversion available again

[Daniel J. Luke]

On Oct 24, 2016, at 2:31 PM, Rainer Müller  wrote:
> Existing developers need to request to be added to this team by sending
> a mail to the macports-infra mailing list as instructed in the announcement.

of course, sorry I apparently can't read and follow directions :)

-- 
Daniel J. Luke



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

Re: Moving to GitHub: Status Update, Action Required

[Ryan Schmidt]

> On Oct 25, 2016, at 6:54 AM, Rainer Müller  wrote:
> 
> On 2016-10-25 10:36, Ryan Schmidt wrote:
>> 
>> 
>> On Oct 24, 2016, at 17:57, Clemens Lang  wrote:
>> 
 On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote:
 A description of how exactly one would rebase (potentially squash and
 history-rewrite) a submitted PR onto current master should be on our
 WorkingWithGit wiki page.
>>> 
>>> the easiest approach is just clicking the button that does this on
>>> GitHub. Of course there's also a way to do it from the command line.
>> 
>> We should document, with screenshots, the specific buttons that should be 
>> clicked to achieve this, for the benefit of those developers like me who are 
>> not that familiar with git and GitHub. 
> 
> Keeping such a documentation with screenshots updated to the current
> GitHub release seems excessive. The GitHub documentation already has
> screenshots. We should not try to recreate it, but rather place the
> links to the relevant sections.
> 
> https://help.github.com/articles/merging-a-pull-request/

As long as we don't just link, but in cases where their documentation offers 
multiple choices, tell the user which of those choices to use.


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

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[Ryan Schmidt]

> On Oct 25, 2016, at 7:30 AM, René J.V. Bertin  wrote:
> 
> I've been noticing "Failed to open portfile from registry" errors during 
> certain operations like reinstalling (port -n upgrade --force).

I don't know the answers to your questions, but I wanted to mention that I also 
have noticed the "Failed to open portfile from registry" error far more often 
than seems normal to me. ("Never" would seem normal to me.)

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

"Failed to open portfile from registry" while reinstalling because of configure.optflags

[René J . V . Bertin]

Hi,

I've been noticing "Failed to open portfile from registry" errors during 
certain operations like reinstalling (port -n upgrade --force). This turned out 
due in part to something I changed in one of my own portgroups, but after 
correcting that errors remained.

I've finally traced them down to my use of configure.optflags on the 
commandline, in order to pass in more than 1 compiler option. Curiously I have 
been doing this "for ages", and I have the impression that I did not get the 
error message. That may be incorrect: it can also be I simply didn't pay 
attention to them.

Anyway, after adding some debug output to relevant functions in "base" I see 
this when I reinstall port:bzip2 (doesn't use portgroups):

{{{
DEBUG: Uninstalling bzip2 1.0.6_0
DEBUG: Changing to port directory: 
/opt/local/var/macports/registry/portfiles/bzip2-1.0.6_0/7139f380a4b4965aac474caa6
89d42d0545960fe90e96ec50794eac2e1b2f4b5-2404
DEBUG: workername=interp1 options=ports_nodeps yes configure.optflags {"-O3 
-g"} ports_upgrade_force yes ports_ignore
_different yes ports_force yes ports_autoclean no subport bzip2
DEBUG: set option ports_nodeps to "yes"
DEBUG: set option configure.optflags to ""-O3 -g""
DEBUG: set option ports_upgrade_force to "yes"
DEBUG: set option ports_ignore_different to "yes"
DEBUG: set option ports_force to "yes"
DEBUG: set option ports_autoclean to "no"
DEBUG: set option subport to "bzip2"
}}}
snip
{{{
Warning: Uninstall forced.  Proceeding despite dependencies.
DEBUG: Changing to port directory: 
/opt/local/var/macports/registry/portfiles/bzip2-1.0.6_0/7139f380a4b4965aac474caa689d42d0545960fe90e96ec50794eac2e1b2f4b5-2404
DEBUG: workername=interp2 options=configure.optflags {-O3 -g} ports_nodeps yes 
ports_ignore_different yes ports_upgrade_force yes ports_force yes subport 
bzip2 ports_autoclean no ports_nodepcheck yes
DEBUG: set option configure.optflags to "-O3 -g"
DEBUG: wrong # args: should be "set varName ?newValue?"
while executing
"set user_options(configure.optflags) -O3 -g"
invoked from within
"$workername eval set user_options($opt) $val"
(procedure "macports::worker_init" line 123)
invoked from within
"macports::worker_init $workername $portpath $porturl 
[macports::getportbuildpath $portpath] $options $variations"
(procedure "mportopen" line 39)
invoked from within
"mportopen file://${portfile_dir}/ [array get options_array] $variations"
(procedure "mportopen_installed" line 28)
invoked from within
"mportopen_installed [$port name] [$port version] [$port revision] [$port 
variants] $options"
Warning: Failed to open Portfile from registry for bzip2 @1.0.6_0 (wrong # 
args: should be "set varName ?newValue?"); 
registry=7139f380a4b4965aac474caa689d42d0545960fe90e96ec50794eac2e1b2f4b5-2404
--->  Deactivating bzip2 @1.0.6_0
DEBUG: deactivating file: /opt/local/share/man/man1/bzmore.1.gz
}}}

I deduce from this that a nested interpreter is invoked at some point, which 
causes the quotes on my configure.optflags value to get lost.

I don't think this can be due to anything I might have changed, but is there an 
easy way to figure out where that nested interpreter is called? My first guess 
would be the eval on the abovementioned line 123, but in that's evidently not 
the case (the "set option configure.optflags" DEBUG message is printed *before* 
that eval and already lacks the quotes). Printing a backtrace each time I print 
the workername= debug message could help.

Or maybe this is in fact something that's expected to happen?

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

Re: Moving to GitHub: Status Update, Action Required

[Rainer Müller]

On 2016-10-25 10:36, Ryan Schmidt wrote:
> 
> 
> On Oct 24, 2016, at 17:57, Clemens Lang  wrote:
> 
>>> On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote:
>>> A description of how exactly one would rebase (potentially squash and
>>> history-rewrite) a submitted PR onto current master should be on our
>>> WorkingWithGit wiki page.
>>
>> the easiest approach is just clicking the button that does this on
>> GitHub. Of course there's also a way to do it from the command line.
> 
> We should document, with screenshots, the specific buttons that should be 
> clicked to achieve this, for the benefit of those developers like me who are 
> not that familiar with git and GitHub. 

Keeping such a documentation with screenshots updated to the current
GitHub release seems excessive. The GitHub documentation already has
screenshots. We should not try to recreate it, but rather place the
links to the relevant sections.

https://help.github.com/articles/merging-a-pull-request/

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

Re: Moving to GitHub: Status Update, Action Required

[Ryan Schmidt]

On Oct 24, 2016, at 17:57, Clemens Lang  wrote:

>> On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote:
>> A description of how exactly one would rebase (potentially squash and
>> history-rewrite) a submitted PR onto current master should be on our
>> WorkingWithGit wiki page.
> 
> the easiest approach is just clicking the button that does this on
> GitHub. Of course there's also a way to do it from the command line.

We should document, with screenshots, the specific buttons that should be 
clicked to achieve this, for the benefit of those developers like me who are 
not that familiar with git and GitHub. 



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