-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi!
I assume by resources you are refering to buildbot slaves. I guess, running that buildbot tasks is a rather CPU and IO intense more than it needs connectivity. So if I'm getting it right all needed is to rent or collocate a box in a datacenter and opt for lots of CPU power and fast IO. Maybe we should compare offers of different datacenters for that, once we know the expected cost by year, it's likely that we can find an arrangement that Allnet could be the sponsor for that and I'd be happy to see that happening. Cheers Daniel On 02/22/2012 05:35 PM, Travis Kemen wrote: > Daniel, > > Currently the buildbot only builds the default configuration for most the > arches. The issue with adding all the profiles is that there are not enough > resources to build them in a timely fashion. Looking at it today and it is > currently taking 4 days to build all the branches (this is with some failing > to > build thus speeding up the builds). If we had enough resources to build the > profiles it would be nice. > > Travis > > On Tue, Feb 21, 2012 at 9:20 AM, Daniel Golle <dgo...@allnet.de > <mailto:dgo...@allnet.de>> wrote: > > From what I can see the rt305x port is quite stable now and therefore I'd > like > to see downloadable snapshot images for the available rt305x boards. > So I was thinking about what prevents buildbot from building images for > both > ramips profiles, rt305x and rt288x. First I was thinking there could just > be > another buildbot task with another .config file for rt305x and that's it. > > Now I realize that both builds would probably be able to share there > packages, > and as far as I can see that wouldn't even be a problem for kmod* > packages if we > just make sure the .config for both kernels ends up to be similar enough. > To see if this works, I installed kmod-ipv6 on a HW550-3G Rt3052F board > and see > that it works (though the module was compiled with the rt288x profile and > therefore rt288x kernel config). I know that this might not be applicable > for > modules using ramips specific platform details which do differ in rt288x > and > rt3xxx, such as dwc_otg. > > How do you imagine the solution to look like? > From what I can see, the options are: > * merge rt288x with rt305x and try to manage with runtime detection > (+) only one kernel, only one set of modules > (-) increased kernel size would probably make it impossible to use that > on > some very resource-constraint rt288x systems > (-) quite a lot of work > > * have seperate package sets for rt2880 and rt305x > (+) easy to do > (-) quite a lot of unneeded redundancy (for buildbot and in terms of > diskspace > on downloads.openwrt.org <http://downloads.openwrt.org>) > > * make kmod-* packages have the profile name as part of the filename and > have > seperate package lists for each profile > (+) not as difficult > (+) most efficient and no difference in runtime resource consumption > (-) requires changes to the build system > > > Looking forward to your comments! > > > Cheers > > Daniel > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org <mailto:openwrt-devel@lists.openwrt.org> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > - -- ALLNET GmbH ; Maistr. 2 ; D-82110 Germering ; Germany Tel. +49-89-89422222 - Fax +49-89-89422233 http://www.allnet.de email: Daniel Golle <dgo...@allnet.de> Schulungs-/Veranstaltungsprogramm: http://www.802lab.de<http://www.802lab.de/> Geschäftsführer: Wolfgang Marcus Bauer Handelsregister München B 95922 ; UST-ID-Nr. DE 128214294 ; St.-Nr.117/115/00164 WEEE-Reg.-NR. DE 13101093 Bankverbindung: Sparkasse Fürstenfeldbruck KTO: 2774594 ; BLZ: 70053070 Swift-Code: BYLADEM1FFB ; IBAN: DE61700530700002774594 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPRTIvAAoJEDy9cKN/1Et0uxoQAKVVNR6TvadzVVSN9vuFHBEz ymuyo9kha6uRvT/Pvm3dqA828/Uvqv1j5/ooQAuXs2W74dVVwiuvBAFfvYLBGzcx Hxa3423ci+aZNBHti8Qf3ephH/qfoIxnZgXsYpEY5BEHL/OAqKHp9SXpOkqy4nT8 WIaLhtFE1MsxXevm2D/u69N0Z0inD64MYNJdHuggZGCyuGXKe4AYVTyg8FXPHgQP Nk8vmT9a3A/SbWjmO+eyiMS3WGiFWkb7MxvGLghmUZGaPGCMVJx66LAlBo94ovWP MYzdyNNipKsAZq6U24v27Zw7jG0HpECTY6RpIeAesw1/fm2fWbg71pKuQAocoer5 8SCwZP2PhQHAkSyVS1yQ1NSa5xIfsIAAD+hgxFEeWjP2hChu6o7ibJaRiXipc+9h Nrr17Uw6/89PUF6uyg99WIP/kzKH944fqKwUxzgLzyCTUuluKguwFj2FraIE0S3+ ZNkODxSWqBvbKlQxKGLjluCt/y4IAtl2+OvSj6ScObgw7mLSRw3vYn8VIv51yLiL w1WVJxeBS99icP3Dckbt28Wz+heeb8zcEmULSqrVJvjVc62VMf62AG0cM14+N887 A3nb2zvq08eKntzyTndrnJmuz5jnY3Fr8fMpe/rrAulNj2j5ZFsmDwcPm7lTJFZq B31nqd/BaQD3qKEHoD+R =tnr6 -----END PGP SIGNATURE----- _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
