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