13:01 #startmeeting 13:01 Meeting started at 13:01:41 UTC. The chair is alicef. Information about MeetBot at https://github.com/GKernelCI/Gmeetbot 13:01 Available commands: action, commands, idea, info, link, nick 13:02 rollcall 13:02 !team kernel 13:02 mpagano: kveremitz Whissi 13:03 #topic rollcall 13:03 please say hi if you are around 13:06 hi 13:07 anyone around ? 13:08 i'm around ;-P 13:08 * mgorny hides 13:09 :) 13:09 is dinner time there? 13:10 hi 13:10 in EU? it's 3 PM, so some people eat around the time, yeah 13:10 hi montjoie :) 13:10 !time mgorny 13:10 alicef: Europe - Warsaw - Sun Jul 25 15:10 CEST 13:11 is night here after dinner time 13:11 but I didn't eat yet 13:11 mpagano: kveremitz Whissi 13:12 !proj kernel 13:12 (kernel@gentoo.org) alicef, blueness, chainsaw, mpagano, whissi, zorry 13:12 oooh it worked 13:12 mgorny everything ok ? 13:13 i suppose so 13:13 you? 13:13 not bad :) 13:13 News from kernel: 5.13.5: stable 13:13 News from kernel: 5.10.53: longterm 13:13 News from kernel: 5.4.135: longterm 13:13 eh ? as we do the meeting ... 13:14 I think we should wait at least mpagano 13:14 for the meeting to start 13:15 alicef: eat something while you wait ;-) 13:16 * alicef is opening a peanuts can 13:16 I think we can at least start with gkernelci 13:16 #topic gkernelci 13:17 not so much happened. I did some small code fixes and updated the kernel version 13:17 now is supporting 5.13 and next 5.14 13:18 and I requested a dedicated server as the compilation time is becoming a bootle neck 13:18 mgorny did you give a look a gkernelci ? do you have any opinion ? 13:19 only a brief look at some point 13:19 inspired me for src_test() in dist-kernel 13:19 is useless ? :/ 13:19 oh nice :) 13:19 at some point would be nice to deduplicate work 13:19 since i need to build+test 5.4/5.10/5.13 anyway for gentoo-kernel-bin 13:20 takes around 20 min per kernel version per arch on my pc 13:20 are you doing also kselftest ? 13:22 are you thinking that by building and testing gentoo-kernel-bin gkernelci become useless ? 13:22 gentoo-sources need anyway to be tested before the release 13:22 and that is what is currently doing gkernelci 13:23 no, not yet 13:23 that not yet is scary :P 13:23 i need to investigate kselftest at some point 13:23 (i was replying wrt kselftest) 13:24 ah is about kselftest :) 13:24 what do you mean by deduplicate work ? 13:25 not sure yet 13:25 would be nice not to do the same thing twice 13:25 yes but we are still releasing two packages 13:25 either make gkernelci build gentoo-kernel images, or improve src_test() to make it equiv to gkernelci 13:26 also if you improve src_test() we need still to test each linux-patches commit 13:26 how does gkernelci test new kernel versions? do you start it before pushing gentoo-sources or after? 13:26 is doing both 13:27 ah, ok 13:27 but the test of pushing gentoo-sources is still not yet finished 13:27 i suppose no good solution then yet 13:27 is actually testing everything under sys-kernel/* 13:28 but currently is just using ebuild 13:28 we would find it helpful to have access to new releases of genpatches early though 13:28 so we could start testing and building gentoo-kernel before gentoo-sources are pushed 13:29 when gentpatches are released we are making also gentoo-sources 13:29 usually at same time 13:29 ah, ok 13:30 i thought you were testing it first 13:30 gkernelci is testing each commit on linux-patches 13:30 ah 13:30 linux-patches get build and tested 13:30 if they work we make genpatches 13:30 than gentoo-sources 13:30 is it doing every single commit or skipping commits if many happen at once? 13:31 becouse in some cases we broke linux-patches 13:31 like I see few mangled commit but it happened 13:31 and gkernelci can catch such things 13:32 I think is doing each commit 13:33 is rare to have many commits happen at once 13:33 btw shouldn't the topic be updated for 5.12 EOL? 13:34 mgorny: you are right ! 13:34 but I have no idea how to change a topic during a meeting. bit worried that it mangle the bot 13:34 :P 13:36 there's one more suggestion from us 13:36 we think it would be better if genpatches version carried the full kernel version 13:36 i.e. instead of genpatches version 22 correspoinding to 5.12.19 13:36 it would be version 19 13:36 and then 19.1, 19.2 etc. if need be 13:37 right now it's hard to guess which genpatches version corresponds to which kernel version 13:37 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 I'm actually not sure how gentoo-kernel-bin work 13:39 as I'm honestly not using it 13:40 it installs binary kernel + modules and compiles a minimal source tree needed to build kernel modules 13:41 and is using genpatches? 13:41 yes 13:42 GENPATCHES_P=genpatches-${PV%.*}-$(( ${PV##*.} + 2 )) 13:42 I see 13:43 gentpatches is getting up with revision 13:43 so is not releted with the kernel version 13:43 that's what i'd like to change 13:43 there's rarely more than one revision for kernel version 13:44 and it would be convenient to have both versions in sync 13:44 for example if we have gentoo-sources-5.19.10-r2 genpatches will be probably something like 12 13:44 as we have genpatches for 10 10-r1 e 10-r2 13:44 and i'd like to see instead genpatches 10-r2 or sth like that 13:46 that's interesting 13:47 we still need the opinion of mpagano 13:47 sure 13:47 and I think bumping genpatches with kernel version is not so straight forward as doing 13:47 n+1 13:48 we also go out of the gkernel topic :P 13:48 #topic deblob 13:49 i think the newest deblob patch is good 13:49 about deblob I think we already had a discussion on the mailing list :) 13:49 mgorny thanks 13:50 I don't think we need furter discussion 13:51 #kernel eapi mpagano whissi 13:51 #topic kernel eclass eapi mpagano whissi 13:51 about kernel eapi I see mpagano that update the kernel eclass to eapi 7 and 8 13:51 still gentoo-sources are eapi 7 13:52 but I think we can alrady start to move it to eapi 8 13:52 #topic mgorny points 13:53 mgorny: if you have any other topic :) 13:53 but would still need mpagano opinion also 13:54 montjoie: anything to add about gkernelci ? 13:55 5 13:56 4 13:56 3 13:56 2 13:56 hmm 13:56 a rough idea that we could consider 'restarting' or merging patches in genpatches 13:57 e.g. 4.4 series has 276 patches to bring the kernel from 4.4 to 4.4.276 13:57 applying that many patches is slow, and they often replace one another 13:58 other distribution are usually keeping kernel sources branches and bumping that 13:59 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 but is actually much more slow to keep all the kernel source code 13:59 like a script doing the periodical merge ? 14:00 or modification to how genpatches are generated 14:00 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 as we can know which patch got bumped on which kernel version 14:01 i'm only talking of the 1* patches that backport upstream changes 14:01 ./1000_linux-4.4.1.patch 14:01 ./1001_linux-4.4.2.patch 14:01 ./1002_linux-4.4.3.patch 14:01 ./1003_linux-4.4.4.patch 14:01 ./1004_linux-4.4.5.patch 14:01 these ones 14:01 that's one of the pro that I can think about having it separated 14:01 yes but if for example 14:02 linux 4.4.4 have a security issue in one of the patch 14:03 sorry 14:04 I'm just think that having separate patches make more easy to search things 14:04 but is a valid point 14:05 do you think of any other benefit other than just make apply more fast ? 14:05 smaller genpatches archive probably 14:05 I think apply last just few seconds currently 14:06 around 10 seconds on tmpfs, i guess 14:06 10-15 14:06 would be easier to measure if they were applied during src_prepare 14:06 we can add this and genpatches following genkernel version as topic for the next meeting when we have also mpagano :) 14:07 as mpagano have a much better vision on genpatches future 14:08 genpatches following kernel version and merging kernel incremental patches 14:09 I think the bot can take note 14:09 alicef: if i combine the first 200 patches into one diff, genpatches goes from 4.1M to 1.2M 14:09 #note genpatches following kernel version and merging kernel incremental patches 14:10 #IDEA genpatches following kernel version and merging kernel incremental patches 14:10 alicef: I have some patch to add to gkernelci, mostly adding "native build" and a way to configure workers via yaml 14:10 they are aleady done, but I need to polish them 14:10 #idea montjoie have patch to add to gkernelci, mostly adding "native build" and a way to configure workers via yaml 14:11 nice ! 14:11 mgorny: that's a nice achivement :) 14:12 let's ask mpagano opinion on the next meeting 14:13 wow configure workers via yaml would be really useful 14:13 still we need to found a way for having only one http server :/ 14:14 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 for example native build for non-x86 is cpu hungry 14:18 I see 14:18 do you have any draft code ? 14:19 if you have something you should send the pull request so I can review and help out 14:20 just write draft in the title so I know is not finished yet 14:21 any other topics ? 14:21 5 14:21 4 14:21 3 14:22 2 14:22 1 14:22 thanks mgorny 14:22 thanks montjoie 14:23 alicef: I have! 14:23 is already 23 minutes over let's close the meeting 14:23 it's not meeting related 14:23 juippis yes 14:23 #topic open 14:24 but since you're around, where did we left off with gkernelci github pr support? 14:24 since mgorny manages the gentoo github if there was some restriction from that side 14:24 right 14:24 now'd be a good time to talk about it 14:24 we solved that. I can now see the pr code from github 14:25 I tested it works on sys-kernel* but not on any other PRs 14:25 for regular packages 14:25 does the build server catch the request with the gkernelci label, or does it match the sys-kernel/* 14:25 yes is still not enabled for regular packages 14:26 currently the server is overloaded even for sys-kernel/* 14:26 can we enable it for regular packages with a custom label? Like gkernelci 14:26 ah 14:26 that's why I requested a dedicated machine 14:26 yes, I don't want it to test everything automatically ever. It'd be requested through a github label 14:26 sorry I have still have to work on the custom label script 14:26 that only the devs can apply 14:27 I checked it few weeks ago but I have made no progress yet 14:27 okay, it's good to know where we're at currently! 14:27 yes 14:27 gkernelci is getting each label for each pull request 14:28 currently 14:28 so gkernelci know when the gkernelci label get activated and disabled 14:29 I still need to find a way to link that to a build trigger action 14:29 I can give you the json code if you are interested 14:29 and point you to the python code related to the parsing 14:30 think I've seen them before but sure, doesn't hurt! 14:31 ok 14:32 still the current server is really slow 14:32 depend from the package it can take hour to finish :( 14:33 juippis: can you give me some package that are you interested to see enabled ? 14:33 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 maybe I can start from that 14:33 just pick any unmerged PR from github :P 14:33 ok :P 14:34 https://github.com/gentoo/gentoo/pull/21784 something like this 14:34 juippis thanks 14:34 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 or EAPI bump 14:34 to test 14:35 yes I will do 14:35 cheers \o 14:35 thanks for the idea 14:36 I will update the issue you open in few hours with what we did 14:36 any other topic? 14:36 5 14:36 4 14:36 3 14:36 2 14:37 1 14:37 thanks juippis mgorny montjoie 14:37 if there are no other topic I will close the meeting 14:38 #endmeeting