On Wednesday 06 August 2008 07:37:26 Joe Peterson wrote:
> You are trying to say it's a 'live' ebuild (i.e. it gets the sources from a
> live source) - that's all. The locking issues are a technical detail
No, the locking issues are the whole point. There are other reasons to want
the package m
On Wed, 06 Aug 2008 00:37:26 -0600
Joe Peterson <[EMAIL PROTECTED]> wrote:
> Zac Medico wrote:
> > To simplify things, how about if we just do a
> > PROPERTIES=live-src-unpack for now, to indicate exclusive access to
> > $DISTDIR during src_unpack? Thats a simple and portable baseline
> > that will
Zac Medico wrote:
> To simplify things, how about if we just do a
> PROPERTIES=live-src-unpack for now, to indicate exclusive access to
> $DISTDIR during src_unpack? Thats a simple and portable baseline
> that will be quite useful even without anything finer grained.
No need for a convoluted and l
On Tue, 05 Aug 2008 23:26:22 -0700
Zac Medico <[EMAIL PROTECTED]> wrote:
> To simplify things, how about if we just do a
> PROPERTIES=live-src-unpack for now, to indicate exclusive access to
> $DISTDIR during src_unpack? Thats a simple and portable baseline
> that will be quite useful even without
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Tue, 05 Aug 2008 22:55:06 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> Would having the ebuild perform locking be unportable or introduce
>> any undesirable complexity? Does it really need to be so
>> fine-grained?
>
>
On Tue, 05 Aug 2008 22:57:28 -0700
Zac Medico <[EMAIL PROTECTED]> wrote:
> Can't we just treat them like other ebuilds except for the thing
> about dependencies? Perhaps more fine-grained attributes could be
> added for additional specificity.
Could do, yes, in which case the name should be someth
On Tue, 05 Aug 2008 22:55:06 -0700
Zac Medico <[EMAIL PROTECTED]> wrote:
> Would having the ebuild perform locking be unportable or introduce
> any undesirable complexity? Does it really need to be so
> fine-grained?
It's not particularly tricky, and the lock code can be moved into an
eclass if ne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Tue, 05 Aug 2008 22:15:11 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> Does this seem like a desirable way to represent the "virtual"
>> attribute? Any suggestions?
>
> Again, I'm not so sure that this doesn't represent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sun, 03 Aug 2008 18:52:43 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> As a substitute for the previously discussed RESTRICT=live value[1],
>> I'd now like you to consider an equivalent PROPERTIES=live-sources
>> setting
On Tue, 05 Aug 2008 22:15:11 -0700
Zac Medico <[EMAIL PROTECTED]> wrote:
> Does this seem like a desirable way to represent the "virtual"
> attribute? Any suggestions?
Again, I'm not so sure that this doesn't represent multiple separable
concepts. It seems to imply:
* that the install cost is eff
On Sun, 03 Aug 2008 18:52:43 -0700
Zac Medico <[EMAIL PROTECTED]> wrote:
> As a substitute for the previously discussed RESTRICT=live value[1],
> I'd now like you to consider an equivalent PROPERTIES=live-sources
> setting. By specifying PROPERTIES=live-sources, an ebuild will be
> able to indicate
Please do NOT use out-of-office, vacation or any other auto-responders
on the lists. It's bad list etiquette.
At the very least, it will get you removed from every list, at worst
I'll block your address at the listserv as well, to cut down on how much
junk I have to filter through.
Both of the f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I'd like you all to consider a PROPERTIES=virtual setting that
allows an ebuild to indicate that it installs no files and serves
only as a layer of dependency indirection. This will be another use
for the new PROPERTIES metadata variable
I will be out of the office starting 04/08/2008 and will not return until
25/08/2008.
Alexis Ballier wrote:
> Somehow I read the sentence differently: it seems pointless to ban
> competent people for so-called anti-social behavior from easily
> pushing technical contributions and still let them contribute to other
> communication medias where such an anti-social behavior is much mor
On Tue, 5 Aug 2008 20:55:02 +0100
David Leverton <[EMAIL PROTECTED]> wrote:
> On Tuesday 05 August 2008 20:45:33 Ben de Groot wrote:
> > It really baffles me that some developers are forcefully retired for
> > anti-social behavior, but are not consequently banned from the
> > places where they dis
On Tuesday 05 August 2008 20:45:33 Ben de Groot wrote:
> It really baffles me that some developers are forcefully retired for
> anti-social behavior, but are not consequently banned from the places
> where they display this behavior, such as our MLs and IRC channels.
I'm not aware of any ex-develo
Lukasz Damentko wrote:
> Fair enough. Let me wrap up the IRC part.
>
> 1. I'd like to ask Council to discuss possible reactions to our
> developer being banned from Freenode without providing us with a
> reason. The situation looks like one of Freenode staffers overreacted
> over something Chris s
> Ciaran McCreesh wrote:
> > > "Alec Warner" <[EMAIL PROTECTED]> wrote:
> > >> I'm a maintainer and I'll say right out that I won't fix things
> > >> unless they make sense to me; regardless of what some council says.
> > >
> > > Then I'd imagine devrel would have to step in.
> >
> > I highly doubt
I will be out of the office starting 04/08/2008 and will not return until
27/08/2008.
I will respond upon my return.
I will be on summer vacations and will have no access to my e-mail
Thank you
Kind regards
On Tue, 5 Aug 2008 23:37:36 +0530
"Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 11:04 PM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> > On Tue, 5 Aug 2008 09:50:51 -0700
> > "Alec Warner" <[EMAIL PROTECTED]> wrote:
> >> I'm a maintainer and I'll say right out that I won
On Tue, Aug 5, 2008 at 11:04 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> On Tue, 5 Aug 2008 09:50:51 -0700
> "Alec Warner" <[EMAIL PROTECTED]> wrote:
>> I'm a maintainer and I'll say right out that I won't fix things unless
>> they make sense to me; regardless of what some council says.
>
> Th
On Tue, 5 Aug 2008 09:50:51 -0700
"Alec Warner" <[EMAIL PROTECTED]> wrote:
> I'm a maintainer and I'll say right out that I won't fix things unless
> they make sense to me; regardless of what some council says.
Then I'd imagine devrel would have to step in.
--
Ciaran McCreesh
signature.asc
Des
On Tue, Aug 5, 2008 at 8:28 AM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> On Tue, 5 Aug 2008 08:16:25 -0700
> "Alec Warner" <[EMAIL PROTECTED]> wrote:
>> So assuming the council says we should fix all these issues (and in
>> most cases I would support that assertion)
>> who would fix them? The
On Tuesday 05 August 2008 16:16:25 Alec Warner wrote:
> That being said you are free to chat to Zac about the changes
We've already spoken to him about the changes several times, and it's quite
clear that he either can't or won't understand why it's bad to make
incompatible changes without think
On Tue, 5 Aug 2008 08:16:25 -0700
"Alec Warner" <[EMAIL PROTECTED]> wrote:
> So assuming the council says we should fix all these issues (and in
> most cases I would support that assertion)
> who would fix them? The maintainer is obviously hostile and I doubt
> the council is going to *force* them
On Mon, Aug 4, 2008 at 4:11 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> On Mon, 4 Aug 2008 16:06:11 -0700
> "Alec Warner" <[EMAIL PROTECTED]> wrote:
>> On Mon, Aug 4, 2008 at 11:29 AM, Stephen Bennett
>> <[EMAIL PROTECTED]> wrote:
>> > I would like to put forward the following suggestion for t
On Tue, 5 Aug 2008 10:51:09 +0200
Bruno Prémont <[EMAIL PROTECTED]> wrote:
> Has any progress happened since March for adding support for
> FILE_CAPABILITIES?
Well, Alon still hasn't backed up his claim that Portage supports
capabilities... Fairly important to establish that before anything
else..
On Sun, 23 Mar 2008 Alon Bar-Lev wrote:
> Hello All,
>
> linux-2.6.24 supports file based capabilities via:
> CONFIG_SECURITY_FILE_CAPABILITIES
>
> This enables the use of filesystem attributes in order to store per
> executable capabilities list, more information at [1].
>
> This enables improv
29 matches
Mail list logo
