quick and dirty way...

for p in $(conary rq --install-label [EMAIL PROTECTED]:1-devel| 
grep :source) ; do [ -d $p ] || rmake build --context fl:1-devel    
--flavor 'is:x86(~cmov,~i486,~i586,~i686)' $p  --no-watch ; done

two hours later i have...


[EMAIL PROTECTED] ~]$ rmake q | grep Failed| wc -l ;  rmake q | grep Buil| wc 
-l ; rmake q | grep Queu| wc -l;
19
30
727

expect a more detailed report in the next 48hrs... :)


A.



Ken VanDine wrote:
> Also... building in rMake is very important, not only for quality
> reasons but being able to rebuild the distro for additional
> architectures.  We do really want to get a x86_64 release done.
>
> On 4/2/07, Ken VanDine <[EMAIL PROTECTED]> wrote:
>> You could also add this to your .conaryrc
>>
>> includeConfigFile 
>> http://www.foresightlinux.org/sitemedia/foresight.rmakerc
>>
>> This would ensure we are all using the same rmake settings for 1-devel
>> and 1-contrib.  If we change how we want things built, we can just do
>> it in one place.  This defines the fl:1-devel and fl:1-contrib
>> contexts.
>>
>> --Ken
>>
>> On 4/2/07, António Meireles <[EMAIL PROTECTED]> wrote:
>> > Hi all,
>> >
>> > It would really help a lot to have all the foresight stack rMake 
>> ready.
>> > In short this means that any recipe in fl:1-contrib and fl:1-devel
>> > (fl:1 comes  from it) should  rMook  inside rMake.
>> >
>> > one would need to have in ~/.conaryrc the following
>> >
>> >     [fl:1-devel]
>> >     autoResolve True
>> >     buildLabel                [EMAIL PROTECTED]:1-devel
>> >     installLabelPath          [EMAIL PROTECTED]:1-devel
>> >     [EMAIL PROTECTED]:1-contrib [EMAIL PROTECTED]:1
>> >     [EMAIL PROTECTED]:1 [EMAIL PROTECTED]:devel
>> >
>> > and  then just (inside a work dir) ...
>> >
>> >     cvc co [EMAIL PROTECTED]:1-devel
>> >     cd PKG
>> >     rmake build --context fl:1-devel PKG.recipe
>> >
>> >
>> > Most packages are already rMake friendly but some will fail due to the
>> > inability of conary to catch all buildReqs (specially python and perl
>> > ones). This means that one have to carefully look at rMake output
>> > (usually configure fails) log and  fix buildReqs  to make rMake happy.
>> > Once one gets the package to cook properly inside rMake it's a 
>> matter of
>> > commiting both the changes and the final cooked package.
>> >
>> >              rmake commit SUCESSFULL_rMake_BUILD_JOB_ID
>> >
>> >              (and eventually shadow the pkg to fl:1 (if it is 
>> already there)
>> >
>> > For now, would be nice that *all* new commits were already rMake 
>> ready.
>> > I'll  publish here later a list of all  pkgs  we have atm that  
>> fail to
>> > be  build inside  rMake.
>> >
>> >
>> > All the best,
>> >
>> >
>> > António Meireles (aka doniphon)
>> >
>> >
>> >
>> > _______________________________________________
>> > Foresight-distro mailing list
>> > [email protected]
>> > http://lists.rpath.org/mailman/listinfo/foresight-distro
>> >
>>

_______________________________________________
Foresight-distro mailing list
[email protected]
http://lists.rpath.org/mailman/listinfo/foresight-distro

Reply via email to