Re: Trac down again

[Clemens Lang]

On Wed, Oct 26, 2016 at 09:13:33PM +0200, Marko Käning wrote:
> Where is our trac again?

I've kicked it. Not exactly sure what causes these outages, it's
probably some crawler that fills a queue with requests and causes all of
them to be dropped due to timeout after a while.

We're keeping an eye on it.

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

Re: Git tools for managing patchsets

[Marko Käning]

On 26 Oct 2016, at 17:54 , Michael  wrote:

> Interesting that you mention "Quilt". There is another tool -- Stacked Git -- 
> that is modeled after Quilt.

I don’t see the point of these additional tools on top of git?
If git provides branches, why do I need extra magic to work with them?

Yet, even when I worked with Mercurial I also always wondered why people needed 
all this lark called “Mercurial Patch Queues", which is probably something like 
“Quilt" and "Stacked Git”…

I don’t think anyone would need all this stuff for port maintenance on 
macports/macports-ports.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac down again

[Lawrence Velázquez]

It’s back. I have seen this error a couple of times since the Trac migration.

vq


> On Oct 26, 2016, at 3:18 PM, Marius Schamschula  wrote:
> 
> Hmm.
> 
> Service Unavailable
> 
> The server is temporarily unable to service your request due to maintenance 
> downtime or capacity problems. Please try again later.
> 
> Apache/2.4.10 (Debian) Server at trac.macports.org 
>  Port 443
> 
> Wow. apache24-devel is @2.4.23, but then again the Debian folks back-port 
> patches to the old version rather than updating to the current version...
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 
>> On Oct 26, 2016, at 2:13 PM, Marko Käning > > wrote:
>> 
>> Where is our trac again?
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org 
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

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

Re: Trac down again

[Marius Schamschula]

Hmm.

Service Unavailable

The server is temporarily unable to service your request due to maintenance 
downtime or capacity problems. Please try again later.

Apache/2.4.10 (Debian) Server at trac.macports.org Port 443

Wow. apache24-devel is @2.4.23, but then again the Debian folks back-port 
patches to the old version rather than updating to the current version...

Marius
--
Marius Schamschula



> On Oct 26, 2016, at 2:13 PM, Marko Käning  wrote:
> 
> Where is our trac again?
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

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

Trac down again

[Marko Käning]

Where is our trac again?
___
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 Wednesday October 26 2016 18:50:33 Clemens Lang wrote:

> On Wed, Oct 26, 2016 at 02:17:53AM +0200, René J.V. Bertin wrote:
> > Yeah. There could be a check if the Portfile exists to catch the 1st
> > possibility
> 
> That would introduce a race condition, wouldn't it? Checking whether a
> file exists before doing something with it is a classic mistake.

That depends. I don't see how it would if you check before executing code that 
assumes the file exist:

if {![file exists [$port portfile]/Portfile]} {
ui_warn "[$port portfile]/Portfile] doesn't exist"
} else {
if {![catch {set mport [mportopen_installed ...] etc.} err]} {
} else {
ui_warn "Failed to run/parse Portfile from registry for $portspec 
($err)"
}
}

I'm more used to the effects of the classic mistake where you assume a bit too 
easily that a file always exists ;)

> That information already exists, and you'll see it in debug mode.

Yes, I know $errorInfo is output, but to be honest it's not always easy to 
find, for instance because the logfile is rewritten at least once during a 
`upgrade --force`. I find it more useful to obtain the succinct error message 
from catch and print that in the ui_warn call.

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 02:17:53AM +0200, René J.V. Bertin wrote:
> Yeah. There could be a check if the Portfile exists to catch the 1st
> possibility

That would introduce a race condition, wouldn't it? Checking whether a
file exists before doing something with it is a classic mistake.

> 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.

That information already exists, and you'll see it in debug mode.

> > 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...

That's what I meant when I said "running the Portfile".

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

Re: Git tools for managing patchsets

[Michael]

On 2016-10-26, at 12:25 AM, Joshua Root  wrote:

> On 2016-10-25 10:03 , Michael wrote:
>> 
>> On 2016-10-24, at 2:57 PM, Marko Käning  wrote:
>> 
>>> Hi folks,
>>> 
>>> when I read only the first two paragraphs of this thread...
>>> 
>>> On 24 Oct 2016, at 18:37 , Michael  wrote:
 So since MacPorts is moving to git, and from what I saw in the "how to use 
 git" docs you mentioned, you apparently want people to work with patchsets 
 rebased onto the current head from upstream.
 
 As I was thinking about that, I realized that you lose your history of the 
 patchset in the process.
>>> 
>>> ... I already got the shivers! My goodness, how much did I enjoy the ease 
>>> of Mercurial! Loosing history because of a patch set?!
>>> :-/
>>> 
>>> Well, but I think what you, Michael, are describing, is only needed if you 
>>> work with many patches which aren’t really committed to any repository.
>> 
>> Actually, it's something else. It's the tracking of the history of changes 
>> when those changes get rebased.
>> 
>> This is not about the port files; those work just fine. This is about the 
>> patchsets needed to port a program to OS X.
>> 
>> If I have a set of patches to port version 1 of a program to OS X, what 
>> happens when version 2 of the program comes out?
>> 
>> If you just rebase the patches onto version 2's code, then there is no 
>> connection between the patches for v1 and v2; there's no good way to compare 
>> how your patches for version 1 compared to the patches for version 2, or 
>> version 3. Etc.
>> 
>> The answer is, that there are now two good methods for doing this. Git for 
>> Windows has one method (in fairness, I did not understand it, it seems 
>> mostly manual, but has been developed/improved over years), and the 
>> just-released git-series has a second one (based around extensions to normal 
>> git commands).
> 
> The real work of updating patchsets (which are effectively the same thing as 
> a branch) can't really be automated. You have to resolve the conflicts 
> manually because you have to understand what the patches are actually doing.
> 
> The parts that can be automated are handled by a tool like quilt. It looks 
> like git-series does something similar but handled more like a real git 
> branch.
> 
> - Josh

Interesting that you mention "Quilt". There is another tool -- Stacked Git -- 
that is modeled after Quilt.

(I have never used either, and cannot comment)

---
Entertaining minecraft videos
http://YouTube.com/keybounce

___
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]

Follow-up : I do NOT see the error (due to configure.optflags) when I do `port 
-n upgrade`.

I think this suggests that `upgrade --force` does something recursive which is 
responsible for the substitution/dereferencing.

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

Re: Git tools for managing patchsets

[Joshua Root]

On 2016-10-25 10:03 , Michael wrote:


On 2016-10-24, at 2:57 PM, Marko Käning  wrote:


Hi folks,

when I read only the first two paragraphs of this thread...

On 24 Oct 2016, at 18:37 , Michael  wrote:

So since MacPorts is moving to git, and from what I saw in the "how to use git" 
docs you mentioned, you apparently want people to work with patchsets rebased onto the 
current head from upstream.

As I was thinking about that, I realized that you lose your history of the 
patchset in the process.


... I already got the shivers! My goodness, how much did I enjoy the ease of 
Mercurial! Loosing history because of a patch set?!
:-/

Well, but I think what you, Michael, are describing, is only needed if you work 
with many patches which aren’t really committed to any repository.


Actually, it's something else. It's the tracking of the history of changes when 
those changes get rebased.

This is not about the port files; those work just fine. This is about the 
patchsets needed to port a program to OS X.

If I have a set of patches to port version 1 of a program to OS X, what happens 
when version 2 of the program comes out?

If you just rebase the patches onto version 2's code, then there is no 
connection between the patches for v1 and v2; there's no good way to compare 
how your patches for version 1 compared to the patches for version 2, or 
version 3. Etc.

The answer is, that there are now two good methods for doing this. Git for 
Windows has one method (in fairness, I did not understand it, it seems mostly 
manual, but has been developed/improved over years), and the just-released 
git-series has a second one (based around extensions to normal git commands).


The real work of updating patchsets (which are effectively the same 
thing as a branch) can't really be automated. You have to resolve the 
conflicts manually because you have to understand what the patches are 
actually doing.


The parts that can be automated are handled by a tool like quilt. It 
looks like git-series does something similar but handled more like a 
real git branch.


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