1 |
Hello all, |
2 |
|
3 |
Another little update on my test, it took me a while to find the actual way |
4 |
to increase the timeout to the maximum (or in other words, get out of the |
5 |
default of 60minutes), but I finally found how. |
6 |
|
7 |
Now I have a job that just tries to bootstrap Gentoo Prefix, the last run I |
8 |
made can be found here: |
9 |
https://dev.azure.com/12719821/12719821/_build/results?buildId=21&view=logs |
10 |
You can see all the log. In this case it failed after 1h35min. It failed |
11 |
compiling GCC 8.2.0-r4. |
12 |
|
13 |
The error was: |
14 |
|
15 |
2018-11-27T03:20:31.7540250Z |
16 |
/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/build/./prev-gcc/xg++ |
17 |
-B/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/build/./prev-gcc/ |
18 |
-B/tmp/gentoo/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ |
19 |
-B/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs |
20 |
-B/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs |
21 |
-isystem |
22 |
/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu |
23 |
-isystem |
24 |
/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include |
25 |
-isystem |
26 |
/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/gcc-8.2.0/libstdc++-v3/libsupc++ |
27 |
-L/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs |
28 |
-L/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs |
29 |
-no-pie -fno-PIE -m64 -O2 -pipe -O2 -pipe -gtoggle -DIN_GCC |
30 |
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall |
31 |
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute |
32 |
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros |
33 |
-Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc |
34 |
gcov.o \ |
35 |
2018-11-27T03:20:31.7545947Z hash-table.o ggc-none.o libcommon.a |
36 |
../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a |
37 |
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -o gcov |
38 |
2018-11-27T03:20:31.7670930Z |
39 |
/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/build/./prev-gcc/collect-ld: |
40 |
106: exec: /tmp/gentoo/usr/x86_64-pc-linux-gnu/bin/ld: Invalid argument |
41 |
2018-11-27T03:20:31.8025313Z collect2: error: ld returned 2 exit status |
42 |
2018-11-27T03:20:31.8026192Z Makefile:2935: recipe for target 'gcov' failed |
43 |
|
44 |
In the end of the log we get the usual: |
45 |
|
46 |
2018-11-27T03:23:00.8458538Z * ERROR: sys-devel/gcc-8.2.0-r4::gentoo |
47 |
failed (compile phase): |
48 |
2018-11-27T03:23:00.8480853Z * emake failed |
49 |
2018-11-27T03:23:00.8501574Z * |
50 |
2018-11-27T03:23:00.8524914Z * If you need support, post the output of |
51 |
`emerge --info '=sys-devel/gcc-8.2.0-r4::gentoo'`, |
52 |
2018-11-27T03:23:00.8550010Z * the complete build log and the output of |
53 |
`emerge -pqv '=sys-devel/gcc-8.2.0-r4::gentoo'`. |
54 |
2018-11-27T03:23:00.8572142Z * The complete build log is located at |
55 |
'/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/temp/build.log'. |
56 |
2018-11-27T03:23:00.8593188Z * The ebuild environment file is located at |
57 |
'/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/temp/environment'. |
58 |
2018-11-27T03:23:00.8622509Z * Working directory: |
59 |
'/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/build' |
60 |
2018-11-27T03:23:00.8642956Z * S: |
61 |
'/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/gcc-8.2.0' |
62 |
2018-11-27T03:23:02.9054285Z * |
63 |
2018-11-27T03:23:02.9078678Z * Please include |
64 |
/tmp/gentoo/var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/gcc-build-logs.tar.bz2 |
65 |
in your bug report. |
66 |
|
67 |
The cool thing comes now, how do you actually execute those commands to |
68 |
fill up a bug report? |
69 |
|
70 |
Easy, in the job I upload a Docker image with the system exactly as it was |
71 |
after the boostrap-prefix.sh command. |
72 |
|
73 |
So, if anyone wants to debug what is going on, they just need to do (this |
74 |
works right now): |
75 |
|
76 |
docker pull awesomebytes/gentoo_prefix_latest_image |
77 |
docker run -it awesomebytes/gentoo_prefix_latest_image /bin/bash |
78 |
|
79 |
And you are inside of the box: |
80 |
|
81 |
user@b70d59ff9703:~$ ls |
82 |
bootstrap-prefix.sh start_bootstrap_date.txt |
83 |
user@b70d59ff9703:~$ cat start_bootstrap_date.txt |
84 |
Tue Nov 27 01:52:20 UTC 2018 |
85 |
user@b70d59ff9703:~$ ls /tmp/gentoo |
86 |
bin etc lib lib64 run sbin stage1.log stage2.log stage3.log tmp |
87 |
usr var |
88 |
|
89 |
|
90 |
So you can do those commands suggested by emerge: |
91 |
/tmp/gentoo/tmp/usr/bin/emerge --info '=sys-devel/gcc-8.2.0-r4::gentoo' --> |
92 |
https://pastebin.com/LWS3Bb7S |
93 |
/tmp/gentoo/tmp/usr/bin/emerge -pqv '=sys-devel/gcc-8.2.0-r4::gentoo' --> |
94 |
https://pastebin.com/gipspmnD |
95 |
etc. |
96 |
|
97 |
Or... we could even generate a new bug report automatically from this will |
98 |
all the necessary information, including the instructions on how to get |
99 |
into this box with exactly that state for anyone to help on fixing it. |
100 |
|
101 |
I'll try to dig further in with things that I find useful (and I hope you |
102 |
also find useful). |
103 |
|
104 |
Have a nice day! |
105 |
|
106 |
P.S.: With this I created a bug report easily: |
107 |
https://bugs.gentoo.org/672042 |
108 |
|
109 |
|
110 |
On Tue, Nov 27, 2018 at 2:07 AM Sam Pfeiffer <sammypfeiffer@×××××.com> |
111 |
wrote: |
112 |
|
113 |
> Little update: The full build log is viewable to anyone with the link, so |
114 |
> here you can see the progress of the current job: |
115 |
> |
116 |
> https://dev.azure.com/12719821/12719821/_build/results?buildId=17&view=logs |
117 |
> |
118 |
> (Or I should say, the log of it, for whenever you open the link). |
119 |
> |
120 |
> |
121 |
> On Tue, Nov 27, 2018 at 2:02 AM Sam Pfeiffer <sammypfeiffer@×××××.com> |
122 |
> wrote: |
123 |
> |
124 |
>> Hello everyone, |
125 |
>> |
126 |
>> I'm very excited to see you are interested in adding continuous |
127 |
>> integration! |
128 |
>> |
129 |
>> I don't know that much about continuous integration, I've only used it |
130 |
>> (with systems already setup for me) with in-house Jenkins servers and with |
131 |
>> the ROS buildfarm, based on Travis CI on Github. Also a little bit of |
132 |
>> Gitlab CI in my lab. |
133 |
>> |
134 |
>> I did a bit of research/testing. |
135 |
>> |
136 |
>> Given it's quite a hassle to maintain custom machines, I'd try to use |
137 |
>> some of the free for opensource CI services. I've checked the conditions of |
138 |
>> a few to see which could fit better: |
139 |
>> |
140 |
>> * Gitlab CI: 2000 minutes / month |
141 |
>> * Travis CI: Unlimited minutes / month. But only 50 minutes long per step |
142 |
>> (like per script executed). |
143 |
>> * Azure pipelines: Unlimited minutes / month. 360 minutes long per step |
144 |
>> (like per script executed). |
145 |
>> |
146 |
>> There are probably many more, but those are the ones I knew about. |
147 |
>> |
148 |
>> Given that I wanted to give a try to Azure pipelines. And I did! |
149 |
>> |
150 |
>> I created this repo: |
151 |
>> https://github.com/awesomebytes/gentoo_prefix_ci_test |
152 |
>> |
153 |
>> Where I activated Azure pipelines on it. After around 15min of reading |
154 |
>> the docs and playing around with the web-gui I got my first pipeline |
155 |
>> running. |
156 |
>> |
157 |
>> As an initial setup I thought I would create a Docker image where I |
158 |
>> bootstrap Gentoo Prefix from a Ubuntu 16.04 (as I'm familiar with it with |
159 |
>> my projects). |
160 |
>> |
161 |
>> The repo contains two important things: |
162 |
>> 1) The Dockerfile where I mainly trigger the bootstrap: |
163 |
>> https://github.com/awesomebytes/gentoo_prefix_ci_test/blob/master/Dockerfile |
164 |
>> 2) The configuration file for Azure pipelines on what to do: |
165 |
>> https://github.com/awesomebytes/gentoo_prefix_ci_test/blob/master/azure-pipelines.yml |
166 |
>> |
167 |
>> I've implemented here that it tries to build Gentoo Prefix, and whatever |
168 |
>> the result, it uploads a Docker image to my DockerHub account with the |
169 |
>> results. This implies that: |
170 |
>> If the bootstrap is successful, one can just [docker pull] and [docker |
171 |
>> run] the image to play with Gentoo Prefix. |
172 |
>> If the bootstrap is unsuccessful, one can just [docker pull] and [docker |
173 |
>> run] to find oneself in the exact state of the system after the bootstrap |
174 |
>> command. And one can recover the full console log from the Azure pipelines |
175 |
>> web interface (even tho it would be nice to find out how to post it |
176 |
>> publicly straight away). |
177 |
>> |
178 |
>> If all goes well in a few hours anyone will be able to find in my |
179 |
>> DockerHub account said image (most probably the failed one), just doing: |
180 |
>> docker pull awesomebytes/gentoo_prefix_latest_image:latest |
181 |
>> docker run -it gentoo_prefix_latest_image /bin/bash |
182 |
>> You'll be inside of a Ubuntu 16.04 box with a user called 'user' and with |
183 |
>> all the bootstrapped stuff in /tmp/gentoo. |
184 |
>> |
185 |
>> As curiosity, I checked the machines I got served as 'agents' to run my |
186 |
>> jobs, and they were of the kind: |
187 |
>> |
188 |
>> CPUs: 2x Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz |
189 |
>> RAM: 7GB |
190 |
>> Disk: 94GB free disk space |
191 |
>> |
192 |
>> More than enough to bootstrap Gentoo Prefix! |
193 |
>> |
194 |
>> I don't know if this is the way to go. But at least is interesting to |
195 |
>> have it in mind. |
196 |
>> |
197 |
>> |
198 |
>> On Tue, Nov 27, 2018 at 12:01 AM Benda Xu <heroxbd@g.o> wrote: |
199 |
>> |
200 |
>>> Hi Sam, |
201 |
>>> |
202 |
>>> Sam Pfeiffer <sammypfeiffer@×××××.com> writes: |
203 |
>>> |
204 |
>>> > With Azure announcing unlimited minutes on CI/CD for open source |
205 |
>>> > projects: |
206 |
>>> > |
207 |
>>> https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/ |
208 |
>>> > |
209 |
>>> > Even bootstrapping Gentoo prefix, with pieces of software like gcc |
210 |
>>> > taking very long to compile, is possible. |
211 |
>>> > |
212 |
>>> > The point is: I have been trying to build Gentoo Prefix during the |
213 |
>>> > last days after a few months of break since the last time I touched |
214 |
>>> > the system. And it's failing. I haven't managed yet to bootstrap it |
215 |
>>> > completely. I feel there is no CI/CD setup to catch these issues and |
216 |
>>> > be able to offer a working version of Gentoo Prefix at any time. |
217 |
>>> |
218 |
>>> I completely agree with you. I hope you can carry on this project to |
219 |
>>> setup proper CI for Gentoo Prefix. I am all in for help, portage/ebuild |
220 |
>>> mentoring and coorperation. |
221 |
>>> |
222 |
>>> A CI for Gentoo Prefix has been on my list for ages. Thank you for |
223 |
>>> triggering this. |
224 |
>>> |
225 |
>>> Yours, |
226 |
>>> Benda |
227 |
>>> |
228 |
>>> |
229 |
>> |
230 |
>> -- |
231 |
>> |
232 |
>> *Sammy Pfeiffer* |
233 |
>> PhD Candidate at The Magic Lab within UTS. |
234 |
>> |
235 |
> |
236 |
> |
237 |
> -- |
238 |
> |
239 |
> *Sammy Pfeiffer* |
240 |
> PhD Candidate at The Magic Lab within UTS. |
241 |
> |
242 |
|
243 |
|
244 |
-- |
245 |
|
246 |
*Sammy Pfeiffer* |
247 |
PhD Candidate at The Magic Lab within UTS. |