On Monday 31 July 2006 10:37, Jim Fulton wrote:
> Thoughts?
Amen to all of it! It is one of the frustrating things about PAU. I cannot get
easily to the principal id unless I really authenticate, which was always a
pain in the but..
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (
On 7/31/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
If you ask me, the slipping of the Zope 3 June release is mostly due to
the lack of a release manager. If we had a release manager who'd kick
people's asses, we might have more betas since the first one and we
might even have a fina
Jim Fulton wrote:
On Jul 31, 2006, at 2:02 PM, Philipp von Weitershausen wrote:
...
If you ask me, the slipping of the Zope 3 June release is mostly due to
the lack of a release manager. If we had a release manager who'd kick
people's asses, we might have more betas since the first one and we
m
The Buildbot has detected a failed build of Zope3 branches 3.2 2.4 FreeBSD
tmiddleton.
Buildbot URL: http://buildbot.zope.org/
Build Reason: changes
Build Source Stamp: 6793
Blamelist:
adamg,alecm,andreasjung,baijum,benji,benji_york,ctheune,dobe,dominikhuber,fdrake,frerich,gotcha,hdima,jens,jim
On Jul 31, 2006, at 2:02 PM, Philipp von Weitershausen wrote:
...
If you ask me, the slipping of the Zope 3 June release is mostly
due to
the lack of a release manager. If we had a release manager who'd kick
people's asses, we might have more betas since the first one and we
might even have a
On Jul 31, 2006, at 2:06 PM, Philipp von Weitershausen wrote:
...
So I imagine that when I add an authenticator plugin to a PAU, I'll
have
to specify a fully qualified prefix, not just its prefix within the
PAU.
Right?
Right.
JIm
--
Jim Fulton mailto:[EMAIL PROTECT
Jim Fulton wrote:
> When I did the initial design for the pluggable-authentication utility
> (PAU), I came up with a strategy for managing principal ids, in
> retrospect, is overly complicated. This suspicion is supported by the
> fact that I originally got the implementation of this wrong.
Right
Benji York wrote:
> Jim Fulton wrote:
>> I suggest that, for 3.4, we get rid of the PAU prefix option and
>> provide a generation evolution script that, for PAUs with non-empty
>> prefixes, just prepends their prefixes to their plugin prefixes and
>> clears their prefixes. I'm sorely tempted to
Hi Jim,
[...]
> > I think this is not posible. What if you have a PAU with two
> > authenticator plugins in it. Then you can't delegate the
> prefix from
> > the PAU to both authenticator durring a generation and provide a
> > unique plugin prefix on authenticator level.
>
> I said prepend t
On Jul 31, 2006, at 11:30 AM, Roger Ineichen wrote:
I suggest that, for 3.4, we get rid of the PAU prefix option
and provide a generation evolution script that, for PAUs with
non-empty prefixes, just prepends their prefixes to their
plugin prefixes and clears their prefixes. I'm sorely
tempted
Hi Jim,
[...]
> I'd like to get rid of the PAU prefix and simply require that
> authenticator plugins provide system-wide unique ids. This
> can be done by providing suitable prefixes on each plugin.
+1, but I see some problem...
> I suggest that, for 3.4, we get rid of the PAU prefix option
Jim Fulton wrote:
I suggest that, for 3.4, we get rid of the PAU prefix option and
provide a generation evolution script that, for PAUs with non-empty
prefixes, just prepends their prefixes to their plugin prefixes and
clears their prefixes. I'm sorely tempted to do this for 3.3.
Thoughts
When I did the initial design for the pluggable-authentication
utility (PAU), I came up with a strategy for managing principal ids,
in retrospect, is overly complicated. This suspicion is supported by
the fact that I originally got the implementation of this wrong.
An authenticator plugi
Benji York wrote:
[EMAIL PROTECTED] wrote:
The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux tlotze.
This build slave is apparently having some trouble.
Fixed.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev
Benji York wrote:
[EMAIL PROTECTED] wrote:
The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux tlotze.
This build slave is apparently having some trouble. It's reporting that
it can't find gcc:
unable to execute gcc: No such file or directory
I've separately notified th
15 matches
Mail list logo
