On Sun, 1 Apr 2012 22:47:23 +0200
Michał Górny wrote:
> > There's no guarantee, of course, that the amount of space in ${T} in
> > pkg_pretend is anything like the amount of space that will be
> > available for the build, but check-reqs is deliberately designed to
> > be wildly inaccurate.
>
> Ye
On Sun, 1 Apr 2012 19:55:44 +0100
Ciaran McCreesh wrote:
> On Sat, 31 Mar 2012 14:10:50 +0200
> Maciej Grela wrote:
> > I've read the PMS and I haven't found information whether this
> > variable is supposed to be set during pkg_prepare or not. Therefore
> > I ask, what is the proper behaviour h
On 01.04.2012 20:55, Ciaran McCreesh wrote:
> On Sat, 31 Mar 2012 14:10:50 +0200
> Maciej Grela wrote:
>> I've read the PMS and I haven't found information whether this
>> variable is supposed to be set during pkg_prepare or not. Therefore I
>> ask, what is the proper behaviour here ? Is there doc
On Sat, 31 Mar 2012 14:10:50 +0200
Maciej Grela wrote:
> I've read the PMS and I haven't found information whether this
> variable is supposed to be set during pkg_prepare or not. Therefore I
> ask, what is the proper behaviour here ? Is there documentation on
> what special env variables are supp
On 04/01/2012 01:29 AM, Ulrich Mueller wrote:
>> On Sat, 31 Mar 2012, Zac Medico wrote:
>
>>> The problem is that apart from T (and maybe HOME), there seems to
>>> be no other directory that check_reqs.eclass could use for its disk
>>> space check in pkg_pretend. WORKDIR doesn't exist in pkg_*
> On Sat, 31 Mar 2012, Zac Medico wrote:
>> The problem is that apart from T (and maybe HOME), there seems to
>> be no other directory that check_reqs.eclass could use for its disk
>> space check in pkg_pretend. WORKDIR doesn't exist in pkg_* phases.
> How about PWD?
No sure. Do all package
On 03/31/2012 01:56 PM, Ulrich Mueller wrote:
>> On Sat, 31 Mar 2012, Tiziano Müller wrote:
>> and since "pkg_pretend is run separately from the main phase
>> function sequence, and does not participate in any kind of
>> environment saving" it is not guaranteed to be set to the same $T
>> later
2012/3/31 Tiziano Müller :
> Am Samstag, den 31.03.2012, 14:44 +0200 schrieb Ulrich Mueller:
>> > On Sat, 31 Mar 2012, Maciej Grela wrote:
>>
>> > I've read the PMS and I haven't found information whether this variable
>> > is supposed to be set during pkg_prepare or not.
>>
>> There is no such
> On Sat, 31 Mar 2012, Tiziano Müller wrote:
>> The spec seems to be clear that T is legal in all phases, including
>> pkg_pretend.
> Well, I'd say: there is no sane value you can assign to $T since you
> are not allowed to write anything anyway:
> "pkg_pretend must not write to the filesyst
Am Samstag, den 31.03.2012, 14:44 +0200 schrieb Ulrich Mueller:
> > On Sat, 31 Mar 2012, Maciej Grela wrote:
>
> > I've read the PMS and I haven't found information whether this variable
> > is supposed to be set during pkg_prepare or not.
>
> There is no such stage. You mean pkg_pretend, I s
> On Sat, 31 Mar 2012, Maciej Grela wrote:
> I've read the PMS and I haven't found information whether this variable
> is supposed to be set during pkg_prepare or not.
There is no such stage. You mean pkg_pretend, I suppose?
> Therefore I ask, what is the proper behaviour here ? Is there
> d
Hi,
recently, I've tried to compile libreoffice using paludis and I've
noticed the following problem:
8< -
kraken ~ # cave resolve libreoffice
Done: 3905 steps
These are the actions I will take, in order:
r app-office/libreoffice:0
12 matches
Mail list logo
