| 1 |
On 13/02/19 17:06, Fabian Groffen wrote: |
| 2 |
> On 13-02-2019 12:32:08 +0100, Michael Haubenwallner wrote: |
| 3 |
>>> So, with this in mind, I've started experimenting, here's my "progress": |
| 4 |
>>> |
| 5 |
>>> http://bootstrap.prefix.bitzolder.nl/results/ |
| 6 |
>> Nice! |
| 7 |
> 1990-ish nice HTML, but yeah :) |
| 8 |
> |
| 9 |
>>> The idea is to rsync the result after the bootstrap-prefix.sh call to the |
| 10 |
>>> server. I can have setup to be in an "upload" sense. The current call |
| 11 |
>>> (which assumes direct access) can be found in the dobootstrap script I |
| 12 |
>>> currently use to fire off a bootstrap on a platform: |
| 13 |
>>> |
| 14 |
>>> http://bootstrap.prefix.bitzolder.nl/dobootstrap (see DOPUBLISH) |
| 15 |
>> So I'm wondering how to enable myself to provide logs for some more CHOSTs. |
| 16 |
>> What about rsync + ssh via pecker? |
| 17 |
> Yeah, indeed, it will be rsync push to a module (I think I already |
| 18 |
> enabled that). Not to pecker, but bootstrap.prefix.b.n directly. |
| 19 |
> Some script-foo processes through cron and then does the analysis, etc. |
| 20 |
> I think for remote targets (you) we can consider skipping the distfiles. |
| 21 |
> The original idea I had behind shipping them is to make them available |
| 22 |
> for the case where distfiles are no longer found. I usually pull them |
| 23 |
> through my own mirror, but obviously this has the downside of not |
| 24 |
> checking availability. |
| 25 |
> |
| 26 |
> (drop me a private mail, we can discuss the posibilities here to get |
| 27 |
> your target's results pushed.) |
| 28 |
> |
| 29 |
>>> None of these targets are RAP by the way. I think the current CI is |
| 30 |
>>> very good at that. |
| 31 |
>> Absolutely. However, it would be nice if we could integrate the Linux/RAP |
| 32 |
>> results into this overwiew as well - besides the Linux/Guest ones, even |
| 33 |
>> if they share the same CHOST... |
| 34 |
> Yeah, perhaps just putting them aside. I already ran into |
| 35 |
> LATEST_TREE_YES builds that are not the same as just bootstrapping of |
| 36 |
> course. However, I think regarding the push I'd like some secrecy here |
| 37 |
> regarding the access, so that's a slight problem. |
| 38 |
> |
| 39 |
>> Also, just've found https://wiki.gentoo.org/wiki/Prefix/tested where the |
| 40 |
>> 'Last tried' column values seem outdated - maybe CI builds can provide |
| 41 |
>> more recent dates there as well. |
| 42 |
>> |
| 43 |
>>> By the way, no bootstraps succeeded recently, so that's the goal to get |
| 44 |
>>> that triggered so we can focus on fixing it. Just being able to pull in |
| 45 |
>>> the CI success/fail for that would already be a start. |
| 46 |
>> FWIW, I've created a gentoo-prefix project with Azure pipelines, but their |
| 47 |
>> 6 hours limit is too small for Prefix on Cygwin. So I've added my own |
| 48 |
>> Windows VM there: https://dev.azure.com/gentoo-prefix/ci-builds/_build |
| 49 |
>> However, I'm not sure if I should keep that for security concerns... |
| 50 |
>> |
| 51 |
>> BTW, Cygwin 3.0.0-0.8 does have the fork() that works for Gentoo Prefix! |
| 52 |
> Hahaha, that is great news!!! |
| 53 |
> |
| 54 |
> Thanks, |
| 55 |
> Fabian |
| 56 |
> |
| 57 |
I did raise the idea of setting up the "prefix-ci"/"prefix-testing" mailing |
| 58 |
list to get results send to interested parties by email with Michael at |
| 59 |
FOSDEM - how would you feel about this, Fabian - I'm sure there are users |
| 60 |
who might find access to the archives or even live updates useful - the |
| 61 |
#g-prefix IRC channel is moderately active for those of us on it! There are |
| 62 |
already lists for eg. repo-mirror-CI, we have set up a local list for |
| 63 |
Kernel project CI and there is also releng-autobuilds .. so there is a |
| 64 |
precident, if someone can petition Infra to set it up! |
| 65 |
Best regards, |
| 66 |
|
| 67 |
Michael. |
Archives