1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
|
13:01 <alicef> #startmeeting
13:01 <AlicefBot> Meeting started at 13:01:41 UTC. The chair is alicef. Information about MeetBot at https://github.com/GKernelCI/Gmeetbot
13:01 <AlicefBot> Available commands: action, commands, idea, info, link, nick
13:02 <alicef> rollcall
13:02 <alicef> !team kernel
13:02 <alicef> mpagano: kveremitz Whissi
13:03 <alicef> #topic rollcall
13:03 <alicef> please say hi if you are around
13:06 <alicef> hi
13:07 <alicef> anyone around ?
13:08 <mgorny> i'm around ;-P
13:08 * mgorny hides
13:09 <alicef> :)
13:09 <alicef> is dinner time there?
13:10 <montjoie> hi
13:10 <mgorny> in EU? it's 3 PM, so some people eat around the time, yeah
13:10 <alicef> hi montjoie :)
13:10 <alicef> !time mgorny
13:10 <willikins> alicef: Europe - Warsaw - Sun Jul 25 15:10 CEST
13:11 <alicef> is night here after dinner time
13:11 <alicef> but I didn't eat yet
13:11 <alicef> mpagano: kveremitz Whissi
13:12 <alicef> !proj kernel
13:12 <willikins> (kernel@gentoo.org) alicef, blueness, chainsaw, mpagano, whissi, zorry
13:12 <alicef> oooh it worked
13:12 <alicef> mgorny everything ok ?
13:13 <mgorny> i suppose so
13:13 <mgorny> you?
13:13 <alicef> not bad :)
13:13 <AlicefBot> News from kernel: 5.13.5: stable <http://www.kernel.org/>
13:13 <AlicefBot> News from kernel: 5.10.53: longterm <http://www.kernel.org/>
13:13 <AlicefBot> News from kernel: 5.4.135: longterm <http://www.kernel.org/>
13:13 <alicef> eh ? as we do the meeting ...
13:14 <alicef> I think we should wait at least mpagano
13:14 <alicef> for the meeting to start
13:15 <mgorny> alicef: eat something while you wait ;-)
13:16 * alicef is opening a peanuts can
13:16 <alicef> I think we can at least start with gkernelci
13:16 <alicef> #topic gkernelci
13:17 <alicef> not so much happened. I did some small code fixes and updated the kernel version
13:17 <alicef> now is supporting 5.13 and next 5.14
13:18 <alicef> and I requested a dedicated server as the compilation time is becoming a bootle neck
13:18 <alicef> mgorny did you give a look a gkernelci ? do you have any opinion ?
13:19 <mgorny> only a brief look at some point
13:19 <mgorny> inspired me for src_test() in dist-kernel
13:19 <alicef> is useless ? :/
13:19 <alicef> oh nice :)
13:19 <mgorny> at some point would be nice to deduplicate work
13:19 <mgorny> since i need to build+test 5.4/5.10/5.13 anyway for gentoo-kernel-bin
13:20 <mgorny> takes around 20 min per kernel version per arch on my pc
13:20 <alicef> are you doing also kselftest ?
13:22 <alicef> are you thinking that by building and testing gentoo-kernel-bin gkernelci become useless ?
13:22 <alicef> gentoo-sources need anyway to be tested before the release
13:22 <alicef> and that is what is currently doing gkernelci
13:23 <mgorny> no, not yet
13:23 <alicef> that not yet is scary :P
13:23 <mgorny> i need to investigate kselftest at some point
13:23 <mgorny> (i was replying wrt kselftest)
13:24 <alicef> ah is about kselftest :)
13:24 <alicef> what do you mean by deduplicate work ?
13:25 <mgorny> not sure yet
13:25 <mgorny> would be nice not to do the same thing twice
13:25 <alicef> yes but we are still releasing two packages
13:25 <mgorny> either make gkernelci build gentoo-kernel images, or improve src_test() to make it equiv to gkernelci
13:26 <alicef> also if you improve src_test() we need still to test each linux-patches commit
13:26 <mgorny> how does gkernelci test new kernel versions? do you start it before pushing gentoo-sources or after?
13:26 <alicef> is doing both
13:27 <mgorny> ah, ok
13:27 <alicef> but the test of pushing gentoo-sources is still not yet finished
13:27 <mgorny> i suppose no good solution then yet
13:27 <alicef> is actually testing everything under sys-kernel/*
13:28 <alicef> but currently is just using ebuild
13:28 <mgorny> we would find it helpful to have access to new releases of genpatches early though
13:28 <mgorny> so we could start testing and building gentoo-kernel before gentoo-sources are pushed
13:29 <alicef> when gentpatches are released we are making also gentoo-sources
13:29 <alicef> usually at same time
13:29 <mgorny> ah, ok
13:30 <mgorny> i thought you were testing it first
13:30 <alicef> gkernelci is testing each commit on linux-patches
13:30 <mgorny> ah
13:30 <alicef> linux-patches get build and tested
13:30 <alicef> if they work we make genpatches
13:30 <alicef> than gentoo-sources
13:30 <mgorny> is it doing every single commit or skipping commits if many happen at once?
13:31 <alicef> becouse in some cases we broke linux-patches
13:31 <alicef> like I see few mangled commit but it happened
13:31 <alicef> and gkernelci can catch such things
13:32 <alicef> I think is doing each commit
13:33 <alicef> is rare to have many commits happen at once
13:33 <mgorny> btw shouldn't the topic be updated for 5.12 EOL?
13:34 <alicef> mgorny: you are right !
13:34 <alicef> but I have no idea how to change a topic during a meeting. bit worried that it mangle the bot
13:34 <alicef> :P
13:36 <mgorny> there's one more suggestion from us
13:36 <mgorny> we think it would be better if genpatches version carried the full kernel version
13:36 <mgorny> i.e. instead of genpatches version 22 correspoinding to 5.12.19
13:36 <mgorny> it would be version 19
13:36 <mgorny> and then 19.1, 19.2 etc. if need be
13:37 <mgorny> right now it's hard to guess which genpatches version corresponds to which kernel version
13:37 <alicef> I think in this case deduplicate work is not a problem. maybe src_test could keep do something that can help the user testing the kernel? and GkernelCI can keep working on testing the kernel on the developer part of things
13:39 <alicef> I'm actually not sure how gentoo-kernel-bin work
13:39 <alicef> as I'm honestly not using it
13:40 <mgorny> it installs binary kernel + modules and compiles a minimal source tree needed to build kernel modules
13:41 <alicef> and is using genpatches?
13:41 <mgorny> yes
13:42 <alicef> GENPATCHES_P=genpatches-${PV%.*}-$(( ${PV##*.} + 2 ))
13:42 <alicef> I see
13:43 <alicef> gentpatches is getting up with revision
13:43 <alicef> so is not releted with the kernel version
13:43 <mgorny> that's what i'd like to change
13:43 <mgorny> there's rarely more than one revision for kernel version
13:44 <mgorny> and it would be convenient to have both versions in sync
13:44 <alicef> for example if we have gentoo-sources-5.19.10-r2 genpatches will be probably something like 12
13:44 <alicef> as we have genpatches for 10 10-r1 e 10-r2
13:44 <mgorny> and i'd like to see instead genpatches 10-r2 or sth like that
13:46 <alicef> that's interesting
13:47 <alicef> we still need the opinion of mpagano
13:47 <mgorny> sure
13:47 <alicef> and I think bumping genpatches with kernel version is not so straight forward as doing
13:47 <alicef> n+1
13:48 <alicef> we also go out of the gkernel topic :P
13:48 <alicef> #topic deblob
13:49 <mgorny> i think the newest deblob patch is good
13:49 <alicef> about deblob I think we already had a discussion on the mailing list :)
13:49 <alicef> mgorny thanks
13:50 <alicef> I don't think we need furter discussion
13:51 <alicef> #kernel eapi mpagano whissi
13:51 <alicef> #topic kernel eclass eapi mpagano whissi
13:51 <alicef> about kernel eapi I see mpagano that update the kernel eclass to eapi 7 and 8
13:51 <alicef> still gentoo-sources are eapi 7
13:52 <alicef> but I think we can alrady start to move it to eapi 8
13:52 <alicef> #topic mgorny points
13:53 <alicef> mgorny: if you have any other topic :)
13:53 <alicef> but would still need mpagano opinion also
13:54 <alicef> montjoie: anything to add about gkernelci ?
13:55 <alicef> 5
13:56 <alicef> 4
13:56 <alicef> 3
13:56 <alicef> 2
13:56 <mgorny> hmm
13:56 <mgorny> a rough idea that we could consider 'restarting' or merging patches in genpatches
13:57 <mgorny> e.g. 4.4 series has 276 patches to bring the kernel from 4.4 to 4.4.276
13:57 <mgorny> applying that many patches is slow, and they often replace one another
13:58 <alicef> other distribution are usually keeping kernel sources branches and bumping that
13:59 <mgorny> i think it would be more optimal to periodically merge them and make a single patch that bumps e.g. from 4.4 to 4.4.250, and then handle the rest via small patches
13:59 <alicef> but is actually much more slow to keep all the kernel source code
13:59 <alicef> like a script doing the periodical merge ?
14:00 <mgorny> or modification to how genpatches are generated
14:00 <alicef> the interesting that of keeping all patch separated is that if there is a security issue in one of kernel increment is much more fast to look for it
14:01 <alicef> as we can know which patch got bumped on which kernel version
14:01 <mgorny> i'm only talking of the 1* patches that backport upstream changes
14:01 <mgorny> ./1000_linux-4.4.1.patch
14:01 <mgorny> ./1001_linux-4.4.2.patch
14:01 <mgorny> ./1002_linux-4.4.3.patch
14:01 <mgorny> ./1003_linux-4.4.4.patch
14:01 <mgorny> ./1004_linux-4.4.5.patch
14:01 <mgorny> these ones
14:01 <alicef> that's one of the pro that I can think about having it separated
14:01 <alicef> yes but if for example
14:02 <alicef> linux 4.4.4 have a security issue in one of the patch
14:03 <alicef> sorry
14:04 <alicef> I'm just think that having separate patches make more easy to search things
14:04 <alicef> but is a valid point
14:05 <alicef> do you think of any other benefit other than just make apply more fast ?
14:05 <mgorny> smaller genpatches archive probably
14:05 <alicef> I think apply last just few seconds currently
14:06 <mgorny> around 10 seconds on tmpfs, i guess
14:06 <mgorny> 10-15
14:06 <mgorny> would be easier to measure if they were applied during src_prepare
14:06 <alicef> we can add this and genpatches following genkernel version as topic for the next meeting when we have also mpagano :)
14:07 <alicef> as mpagano have a much better vision on genpatches future
14:08 <alicef> genpatches following kernel version and merging kernel incremental patches
14:09 <alicef> I think the bot can take note
14:09 <mgorny> alicef: if i combine the first 200 patches into one diff, genpatches goes from 4.1M to 1.2M
14:09 <alicef> #note genpatches following kernel version and merging kernel incremental patches
14:10 <alicef> #IDEA genpatches following kernel version and merging kernel incremental patches
14:10 <montjoie> alicef: I have some patch to add to gkernelci, mostly adding "native build" and a way to configure workers via yaml
14:10 <montjoie> they are aleady done, but I need to polish them
14:10 <alicef> #idea montjoie have patch to add to gkernelci, mostly adding "native build" and a way to configure workers via yaml
14:11 <alicef> nice !
14:11 <alicef> mgorny: that's a nice achivement :)
14:12 <alicef> let's ask mpagano opinion on the next meeting
14:13 <alicef> wow configure workers via yaml would be really useful
14:13 <alicef> still we need to found a way for having only one http server :/
14:14 <montjoie> alicef: the major need is to have worker list + pass in one central file AND to permit to choose per worker which arch/toolchain to build
14:14 <montjoie> for example native build for non-x86 is cpu hungry
14:18 <alicef> I see
14:18 <alicef> do you have any draft code ?
14:19 <alicef> if you have something you should send the pull request so I can review and help out
14:20 <alicef> just write draft in the title so I know is not finished yet
14:21 <alicef> any other topics ?
14:21 <alicef> 5
14:21 <alicef> 4
14:21 <alicef> 3
14:22 <alicef> 2
14:22 <alicef> 1
14:22 <alicef> thanks mgorny
14:22 <alicef> thanks montjoie
14:23 <juippis> alicef: I have!
14:23 <alicef> is already 23 minutes over let's close the meeting
14:23 <juippis> it's not meeting related
14:23 <alicef> juippis yes
14:23 <alicef> #topic open
14:24 <juippis> but since you're around, where did we left off with gkernelci github pr support?
14:24 <juippis> since mgorny manages the gentoo github if there was some restriction from that side
14:24 <alicef> right
14:24 <juippis> now'd be a good time to talk about it
14:24 <alicef> we solved that. I can now see the pr code from github
14:25 <juippis> I tested it works on sys-kernel* but not on any other PRs
14:25 <juippis> for regular packages
14:25 <juippis> does the build server catch the request with the gkernelci label, or does it match the sys-kernel/*
14:25 <alicef> yes is still not enabled for regular packages
14:26 <alicef> currently the server is overloaded even for sys-kernel/*
14:26 <juippis> can we enable it for regular packages with a custom label? Like gkernelci
14:26 <juippis> ah
14:26 <alicef> that's why I requested a dedicated machine
14:26 <juippis> yes, I don't want it to test everything automatically ever. It'd be requested through a github label
14:26 <alicef> sorry I have still have to work on the custom label script
14:26 <juippis> that only the devs can apply
14:27 <alicef> I checked it few weeks ago but I have made no progress yet
14:27 <juippis> okay, it's good to know where we're at currently!
14:27 <alicef> yes
14:27 <alicef> gkernelci is getting each label for each pull request
14:28 <alicef> currently
14:28 <alicef> so gkernelci know when the gkernelci label get activated and disabled
14:29 <alicef> I still need to find a way to link that to a build trigger action
14:29 <alicef> I can give you the json code if you are interested
14:29 <alicef> and point you to the python code related to the parsing
14:30 <juippis> think I've seen them before but sure, doesn't hurt!
14:31 <alicef> ok
14:32 <alicef> still the current server is really slow
14:32 <alicef> depend from the package it can take hour to finish :(
14:33 <alicef> juippis: can you give me some package that are you interested to see enabled ?
14:33 <juippis> yeah, that's why I don't want to enable it automatically for every PR. Someone will troll and push 100 chromium update PRs
14:33 <alicef> maybe I can start from that
14:33 <juippis> just pick any unmerged PR from github :P
14:33 <alicef> ok :P
14:34 <juippis> https://github.com/gentoo/gentoo/pull/21784 something like this
14:34 <alicef> juippis thanks
14:34 <juippis> but I fear someone will merge that soon. I can / you can make some dummy PR with any m-n package version bump for example
14:34 <juippis> or EAPI bump
14:34 <juippis> to test
14:35 <alicef> yes I will do
14:35 <juippis> cheers \o
14:35 <alicef> thanks for the idea
14:36 <alicef> I will update the issue you open in few hours with what we did
14:36 <alicef> any other topic?
14:36 <alicef> 5
14:36 <alicef> 4
14:36 <alicef> 3
14:36 <alicef> 2
14:37 <alicef> 1
14:37 <alicef> thanks juippis mgorny montjoie
14:37 <alicef> if there are no other topic I will close the meeting
14:38 <alicef> #endmeeting
|