I propose project lead (or member) files a bug to infra for new list, similar to bug 581370 .. (proxy-maint@)
:] MJE On 16/01/19 18:33, Michael Haubenwallner wrote: > Hi Sam, > > On 1/16/19 2:59 PM, Sam Pfeiffer wrote: >> Hello, >> >> Given it's the first time I touch Fedora it took a bit of time to get it >> working (also I had some DNS issues where I couldn't use dnf). >> >> But it's done. > Wow, great job! > >> You can check out the jobs at: >> >> For amd64 (Job called bootstrap_on_fedora_rap_off, Dockerfile >> <https://github.com/awesomebytes/gentoo_prefix_ci/blob/master/initial_bootstrap/Dockerfile.fedora> >> of the job): >> https://dev.azure.com/12719821/12719821/_build/results?buildId=451> For x86 >> (Job called bootstrap_on_fedora_rap_off, Dockerfile >> <https://github.com/awesomebytes/gentoo_prefix_ci_32b/blob/master/initial_bootstrap/Dockerfile.fedora> >> of the job): >> https://dev.azure.com/12719821/12719821/_build/results?buildId=450 >> >> In 5-6h they should be finished. >> >> In general all the builds are here: >> https://dev.azure.com/12719821/12719821/_build?definitionId=2&_a=summary >> >> Given this seems to be running quite nicely. Should I add automated emails >> when builds fail? >> I can do it either adding a script that does it or via the CI interface (I >> think). >> I won't always be able to check it out quick and make a bug report, so maybe >> someone else would like to receive the emails about the failures. > It does make sense to have more than a single person be notified about build > results, > at least on failures - but I do have no strong meaning about the tooling here. > > And yes, I do have build jobs here as well that will never ever fit into some > free cloud, > but their results would do. > > Thanks! > /haubi/ > >> >> >> On Wed, Jan 16, 2019 at 11:28 PM Michael Haubenwallner <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 1/16/19 2:23 AM, Sam Pfeiffer wrote: >> > Hello Michael, >> > >> > Yeah, just tell me which base distro do you want and I'll add a >> nightly job with that one. I just need to find a Docker image for it. >> >> It doesn't really matter, just not Ubuntu (or anything else that does >> 'multiarch'). >> I would suggest Fedora though... >> >> > >> > Will the final Gentoo Prefix, once bootstrapped, be any different from >> the current one I'm bootstrapping? >> >> Yes: It does not contain sys-libs/glibc and sys-kernel/linux-headers. >> >> > (To know if I should also publish automated releases of the >> bootstrapped Gentoo Prefix). >> >> Haven't recognized that you do 'publish automated releases', nice! >> >> As Prefix/Guest is stronger bound to the host OS compared to Prefix/RAP, >> binary releases don't feel that useful here - at least to myself. >> >> Instead, besides x86_64, also x86 (32bit) would be nice - simply using >> 'linux32': >> $ PREFIX_DISABLE_RAP=yes linux32 ./bootstrap-prefix.sh /target/prefix >> noninteractive >> >> Thanks a lot! >> /haubi/ >> >> > >> > >> > On Wed, Jan 16, 2019, 04:38 Michael Haubenwallner <[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> wrote: >> > >> > Hi Sammy, >> > >> > because of Ubuntu inside these build slaves I do understand you >> currently >> > perform Prefix RAP bootstraps only - as this is the default anyway. >> > >> > Do you see a chance to perform Prefix Guest bootstraps as well, >> > even if that would require something other distro than Ubuntu? >> > >> > Otherwise, the only difference is to set the PREFIX_DISABLE_RAP=yes >> > environment variable when executing bootstrap-prefix.sh. >> > >> > Thanks! >> > /haubi/ >> > >> > >> >> >> >> >> -- >> * >> * >> *Sammy Pfeiffer* >> PhD Candidate at The Magic Lab within UTS. >
signature.asc
Description: OpenPGP digital signature
