init txt meeting logsHEADmaster

Signed-off-by: Alice Ferrazzi <alicef@gentoo.org>

3 files changed, 695 insertions, 0 deletions

diff --git a/meeting_logs/2021/gentoo-kernel.2021-03-30-14.00.log.txt b/meeting_logs/2021/gentoo-kernel.2021-03-30-14.00.log.txt
new file mode 100644
index 0000000..eecf12e
--- /dev/null
+++ b/meeting_logs/2021/gentoo-kernel.2021-03-30-14.00.log.txt
@@ -0,0 +1,386 @@
+14:00 <alicef> #startmeeting
+14:00 <AlicefBot> Meeting started at 14:00:24 UTC.  The chair is alicef.  Information about MeetBot at https://github.com/GKernelCI/Gmeetbot
+14:00 <AlicefBot> Available commands: action, commands, idea, info, link, nick
+14:00 <kveremitz> I'm mostly gonna be here, but I have a plumber fixin my hot water today
+14:01 <alicef> #action alicef GKernelCI updates
+14:01 * AlicefBot alicef GKernelCI updates
+14:01 <alicef> kveremitz: ok
+14:01 <alicef> - currently because of improved testing for each linux-patch commit gkernelci became slow.
+14:02 <alicef> - current architecture under test amd64 (clang, gcc) arm64 arm ppc64 sparc
+14:02 <alicef> - GKernelCI logo approval https://bugs.gentoo.org/777972
+14:03 <alicef> #vote GKernelCI builded and tested genpatches can be stabilized (at least writing stable on bugzilla)?
+14:03 <AlicefBot> Please vote on: GKernelCI builded and tested genpatches can be stabilized (at least writing stable on bugzilla)?
+14:03 <AlicefBot> Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname')
+14:04 <alicef> what's this...
+14:04 <alicef> whissi any idea on this ?
+14:04 <Whissi> Well.
+14:04 <mpagano> so no boot test ?
+14:04 <alicef> if not how we can improve it and what tests are missing ?
+14:05 <mpagano> I boot test every one
+14:05 <Whissi> When we decided to stable KV $x, we can use GKernelCI for the next steps, yes.
+14:05 <mpagano> usually Whissi points out major bugs we are waiting on
+14:05 <alicef> boot test should be ok by stabilization page if afair
+14:05 <mpagano> bugs reported on other distros
+14:05 <Whissi> But I don't see GKernelCI ready to tell us when the next version is good for stabilization
+14:05 <mpagano> some from our users, etc
+14:06 <Whissi> We still have to monitor mailing list because we have almost zero test coverage in GKernelCi
+14:06 <alicef> Whissi: sure, I agree
+14:06 <alicef> we are doing kselftest but would be nice to implement specifics test with kselftest or some other tool
+14:07 <Whissi> kselftest is nice to have, yes. But it never catched any serious bugs in LTS I am aware of.
+14:07 <alicef> but still is complicated without the device at hand
+14:07 <Whissi> The minimum possible suites would include xfs test suite for example
+14:08 <Whissi> I think BTRFS has also one
+14:08 <kveremitz> I don't think our automated testing framework can cover enough potential configurations to be used exclusively for stabilisation. I would like to think that upstream already performs basic testing like we are...
+14:08 <alicef> xfs have a specific test suite ?
+14:08 <Whissi> Yes
+14:09 <kveremitz> also, we have always prided ourselves in Gentoo on testing with Real Hardware.
+14:09 <alicef> this one https://github.com/zfsonlinux/xfstests ?
+14:09 <Whissi> I still don't know if you boot a base image. In that case we could also make sure to do some stuff in user space like configuring it to check if it was able to mount an additional LUKS-encrypted partition...
+14:09 <kveremitz> But its a very useful baseline check to see that our patching and toolchains work correctly
+14:09 <alicef> Whissi: yes we boot a base image
+14:09 <alicef> we are hacking stage3 for rootfs
+14:10 <kveremitz> we can build up the rootfs/etc to incorporate more configurations
+14:10 <Whissi> https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/
+14:10 <alicef> luks-encrypted would be useful :)
+14:10 <alicef> I also use luks
+14:10 <kveremitz> what does the lava framework provide?
+14:10 <alicef> Whissi: thanks for the link
+14:10 <alicef> there are lava testsuite
+14:11 <alicef> but they need to be reimplemented for GKernelCI
+14:11 <alicef> https://github.com/Linaro/test-definitions/tree/master/automated/linux
+14:12 <alicef> I don't see xfstests-dev or luks test
+14:12 <kveremitz> is kselftest and lava just pre-defined tests, how can we adapt to test the things we want/need to .. ?
+14:13 <kveremitz> eg. luks, xfs, zfs? etc
+14:13 <alicef> Whissi: can I for example wrote here (https://bugs.gentoo.org/778824) what works with GKernelCI
+14:13 <kveremitz> alicef: is there a roadmap doc for GkernelCI ?
+14:13 <alicef> kveremitz: read kselftest documentation is really nice about how to implement new tests
+14:13 <alicef> kveremitz: no that's why I'm asking
+14:14 <Whissi> alicef: Sorry, I don't understand. What do want to do exactly?
+14:15 <alicef> like works for amd64 or some other architecture under GKernelCI?
+14:15 <alicef> GKernelCI tests can be used in the stabilization bug ?
+14:16 <alicef> I can manually write what work for GKernelCI
+14:16 <alicef> and what not
+14:16 <Whissi> Well, the question would be how we are going to use the results once we decided to go and just wait for GKCI results
+14:17 <kveremitz> alicef: are you proposing filing automated bugs for kernelCI runs? I don't see how the stabilisation bugs can be integrated?
+14:17 <alicef> if could be useful
+14:17 <Whissi> Like GKCI could create commit scripts in tatt style
+14:17 <Whissi> Just post to bugs and we pick up and do the commit..
+14:17 <alicef> yes that would be nice
+14:18 <kveremitz> it would be good to file bugs with upstream test results potentially, so there is one source in Gentoo to check results?
+14:18 <alicef> kveremitz: we are already doing that with kcidb -> kernelci
+14:20 <kveremitz> err.. file Gentoo bugs with upstream test results. Was what I meant :D
+14:20 <kveremitz> to combine data sources
+14:20 <kveremitz> eg. from other distros
+14:20 <Whissi> Wait, I am not sure if we all are talking about the same at the moment :D
+14:21 <Whissi> Let me recap
+14:21 <alicef> kveremitz: yes that is what kernelci is currently working on
+14:21 <alicef> Whissi: thanks
+14:21 <kveremitz> sorry .. I'm probably crossing wires..
+14:21 <Whissi> For now, GKernelCI won't do anything on its own.
+14:21 <alicef> kveremitz: we are going bit off topic
+14:21 <Whissi> Once we decided to stabilize linux-5.10.27 for example
+14:21 <Whissi> because we (humans :p) haven't found any blocking stuff
+14:22 <Whissi> We will do the stabilization bug like we do it all the time
+14:22 <kveremitz> ^ agreed so far :D
+14:22 <Whissi> But in addition, based on CI results, we can mark gentoo-sources stable on our own
+14:22 <Whissi> (after we started normal stabilization)
+14:22 <mpagano> that I like
+14:24 <kveremitz> hmm.. are you implying a parallel process?
+14:24 <kveremitz> and is this a 'global' or 'local' stabilisation 'flag'?
+14:24 <alicef> if we can do xfstest-dev and luks encryption test, how the workflow would be improved ?
+14:26 <Whissi> I don't think that this will really affect the workflow. It will only give us more confidence.
+14:26 <alicef> Whissi: ok
+14:26 <alicef> +1 for whissi workflow
+14:26 <AlicefBot> +1 for whissi workflow received from alicef
+14:27 <alicef> any other vote ?
+14:28 <mpagano> +1
+14:28 <AlicefBot> +1 received from mpagano
+14:28 <mpagano> +1 for mpagano
+14:28 <AlicefBot> +1 for mpagano received from mpagano
+14:28 <kveremitz> from what I am seeing/reading.. there is no change here, process stays the same, but when doing [manual] stabilisations, we can verify GkernelCI results .. right?
+14:28 <mpagano> nice
+14:28 <Whissi> We maybe need to talk about our long term goal regarding fully automatization.
+14:29 <alicef> Whissi: yes
+14:29 <kveremitz> Whissi: hence my question about a Roadmap (this being the normal process for establishing and tracking goals)
+14:29 <alicef> Whissi: also you can open isssues on gkernelci or gentoo bugs about gkernelci
+14:29 <Whissi> My problem is that we don't test on real hardware. While anything we test would be an improvement already vs status quo, we still don't run kernels on real hardware.
+14:29 <Whissi> So we will not test real hardware issues.
+14:30 <Whissi> And the blockers for 5.10 stabilization for example were all i915 and AMD graphics
+14:30 <alicef> Whissi: I would be happy to have some sponsored real hardware machine :D
+14:30 <kveremitz> aye, recent issues have been graphics, ^ and networking
+14:31 <alicef> they should be not complicated to implement the testing part with lava
+14:32 <Whissi> But how would that work?
+14:32 <montjoie> (being late) I have already LAVA tests for luks
+14:32 <alicef> so if you have some machine that is similar to a production machine that you want to test
+14:32 <alicef> montjoie: nice !
+14:33 <alicef> montjoie: how would work implementing real hardware for testing with lava ?
+14:33 <montjoie> I dont understand the question. you mean does it is possible ? or howto ?
+14:33 <Whissi> At work I have created some PXE setups... i.e. these systems will pull in everything needed to boot via network. When a reboot is triggered we have a timer... when the system won't come up until timeout is reached, we assume failure.
+14:34 <kveremitz> Whissi: that sounds useful
+14:34 <montjoie> real hardware is possible (it is what kernelci do)
+14:34 <Whissi> In our case we are using Dell hardware where we can access iDRAC remotely for stuff like power cycle.
+14:34 <montjoie> for x86 I have already some board in LAVA
+14:34 <alicef> yes
+14:34 <kveremitz> how can we integrate this/these systems with GkernelCI ?
+14:35 <Whissi> But I am not sure if this will help us to detect i915 failures for example.
+14:35 <montjoie> you just have to generate a LAVA job
+14:35 <montjoie> my x86 has a i915, point me to a kernel failure and I can try to reproduce
+14:36 <alicef> should be like adding devices for different servers
+14:36 <alicef> something like this https://lava.ciplatform.org/scheduler/alldevices
+14:37 <Whissi> montjoie: See the "[Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues" thread
+14:37 <kveremitz> sounds promising
+14:37 <kveremitz> I thought this was the idea of Lava :)
+14:37 <Whissi> I am not that familiar with LAVA, wondering how LAVA should detect something like that.
+14:37 <montjoie> the only problem in x86 is that pxe is not ~~~reliable for console output
+14:37 <montjoie> I hit many big problem
+14:38 <kveremitz> true .. that's where a BMC/etc would be more useful
+14:38 <kveremitz> wrt remote consoles
+14:38 <montjoie> for example my x86 send s..t to console so... I have a kernel which boot a rootfs, and init is a fake grub shell
+14:38 <kveremitz> Lava should have handling for that .. although it might not
+14:38 <montjoie> then it kexecto final kernel
+14:38 <kveremitz> oof yuk
+14:38 <montjoie> result is 100% stable
+14:39 <montjoie> stable since you use kernel console and not pxe one
+14:39 <kveremitz> stable+reliable is good
+14:39 <montjoie> for CI you NEED reliable
+14:39 <kveremitz> reproducible+consistent, even better :D
+14:39 <kveremitz> right
+14:39 <montjoie> you can deploy this everywhere, I do the same for some shitty ARM board
+14:39 <montjoie> but it is uboot fake in that case
+14:40 <kveremitz> cool .. I
+14:40 <kveremitz> cool, I'd be interested in testing/deploying that across my different hardware also
+14:40 <alicef> Whissi: if you are willing to sponsor a server we could try to add it to lava workflow
+14:40 <kveremitz> although I won't be devising lava tests for some of the known peculiarities :D
+14:41 <montjoie> https://github.com/montjoie/buildroot/blob/montjoie/board/montjoie/kexec/grub/rootfs-overlay/sbin/init for details
+14:41 <kveremitz> *bookmarked*
+14:41 <Whissi> heh, sadly, not possible for me.
+14:41 <Whissi> But we maybe able to ask foundation to do that...
+14:41 <Whissi> Doesn't have to be a beefy server
+14:41 <alicef> Whissi: sure
+14:41 <Whissi> Just a Dell system with proper iDRAC...
+14:42 <alicef> I don't know what server you want to test
+14:42 <kveremitz> I'm sure foundation has toasters :D heh. OSUOSL might be able to help out .. worth asking Ramereth in the channel
+14:42 <alicef> if you give me some specs I can try to ask to foundation
+14:42 <kveremitz> .. #osuosl
+14:42 <alicef> a dell system with iDrac
+14:43 <juippis> I've got some old HP proliant rack computer from 2011-2012 under my bed if that's use for anyone :P
+14:43 <alicef> also infra would be better to have testing enviroments
+14:43 <Whissi> Before we are asking for money/donation it would be cool if we have a working PoC in a lab or something. Would be a shame if we ask for something which we would be unable to use in the end.
+14:43 <montjoie> just for finish the solution, I use a power switch, a energenie-USB (~40€)
+14:43 <kveremitz> Whissi: +1
+14:43 <juippis> I can also visit hetzner in finland if you got foundation funding to place something in there
+14:44 <kveremitz> juippis: +1.. I also have a ProLiant with its .. thing.
+14:44 <alicef> anyway for now whissi can you vote on the workflow you proposed ?
+14:44 <kveremitz> iLo is HP
+14:45 <kveremitz> https://www.hpe.com/us/en/servers/integrated-lights-out-ilo.html and Dell is https://www.delltechnologies.com/en-gb/solutions/openmanage/idrac.htm for ref.
+14:45 <kveremitz> same principle
+14:45 <alicef> and I will try to close the vote
+14:45 <Whissi> +1 for whissi workflow
+14:45 <AlicefBot> +1 for whissi workflow received from Whissi
+14:46 <kveremitz> #votes
+14:46 <kveremitz> heh
+14:46 <montjoie> Whissi: I see your link, but does this can be tested automatacly ?
+14:46 <alicef> #agree on whissi workflow
+14:46 <AlicefBot> AGREED: on whissi workflow
+14:46 <alicef> #voted
+14:47 <Whissi> montjoie: Which link? I posted multiple links ;)
+14:47 <montjoie> [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues" thread
+14:47 <kveremitz> heh I have one of those for my router/modem (usb power switch) attached to a rpi :D
+14:48 <Whissi> montjoie: Well, that's actually my question...
+14:48 <montjoie> time to create an issue to dig this
+14:48 <kveremitz> good idea +1
+14:49 <montjoie> alicef: any place where i915, luks etc test related issue should be created ? ghelper probably since it own the lava generate stuff right ?
+14:50 <alicef> ghelper is ok
+14:50 <alicef> in any case all issues get into the main project folder
+14:50 <alicef> so it dosen't matter too much where you open the issue
+14:51 <alicef> montjoie: -> https://github.com/orgs/GKernelCI/projects/2
+14:51 <kveremitz> 👍
+14:52 <alicef> the only repository that dosen't catch is the gmeetbot probably
+14:53 <alicef> #vote everyone ok with the GKernelCI logo https://bugs.gentoo.org/777972 ?
+14:53 <AlicefBot> Voting still open on: GKernelCI builded and tested genpatches can be stabilized (at least writing stable on bugzilla)?
+14:53 <alicef> +1
+14:53 <AlicefBot> +1 received from alicef
+14:54 <alicef> mpagano: Whissi  ?
+14:55 <Whissi> +1
+14:55 <AlicefBot> +1 received from Whissi
+14:55 <alicef> mpagano: ?
+14:56 <mpagano> +1
+14:56 <AlicefBot> +1 received from mpagano
+14:56 <mpagano> that would be great for me
+14:56 <alicef> we can close the discussion on gkernelci ?
+14:57 <montjoie> Whissi: https://drm.pages.freedesktop.org/igt-gpu-tools/igt-i915-tests.html :D
+14:57 <alicef> montjoie+1
+14:57 <alicef> montjoie +1
+14:57 <alicef> thanks!
+14:57 <Whissi> montjoie: Sure but I don't know if it would catch the reported problem ;)
+14:57 <montjoie> kveremitz: https://storage.kernelci.org/mainline/master/v5.12-rc5/x86_64/x86_64_defconfig/gcc-8/lab-clabbe/baseline-d2500cc.html log of grubfake solution
+14:58 <montjoie> Whissi: I will try
+14:58 <Whissi> Cool, thanks
+14:58 <alicef> if there are no other dicussion topic for gkernelci, let's move to eapi 7
+14:59 <alicef> #action whissi EAPI 7
+14:59 * AlicefBot whissi EAPI 7
+14:59 <kveremitz> I like the idea of artwork approval, but can the amateur lawyers get themselves sorted out, so that this is Feasible? otherwise we can only vote on interest, not action
+14:59 <kveremitz> montjoie: thanks!
+15:00 <mpagano> Whissi: how can we help on EAPI 7
+15:00 <alicef> kveremitz: currently the vote is only interest, there is a discussion if is about law ok or notin another bug
+15:00 <kveremitz> alicef: ok
+15:00 <alicef> Whissi: how we can help?
+15:00 <kveremitz> I vote the legal stuff is fixed :D
+15:01 <kveremitz> And I vote for more artwork :D
+15:01 <kveremitz> #topic
+15:01 <alicef> kveremitz: plese don't go off topic XD
+15:01 <kveremitz> heh
+15:01 <Whissi> Well.
+15:02 <kveremitz> #help
+15:02 <kveremitz> what are the damn thingies LOL
+15:02 <alicef> kveremitz: only chair can do it
+15:03 <Whissi> Like said I was working on completely new EAPI 7 eclasses to get rid of all the old hacks.
+15:03 <kveremitz> Whissi: how far along are you?
+15:03 <juippis> "I was" and not "I am" sounds bad :I
+15:04 <Whissi> But I am stuck because of time. I have a working draft for basic gentoo-sources...
+15:04 <kveremitz> since there is a real chance Someone could commit another 'hack' to the stack to serve Their immediate purposes...
+15:04 <alicef> Whissi: how can we help ?
+15:04 <kveremitz> ^
+15:04 <Whissi> but it would break with some stuff.
+15:04 <juippis> wasn't there a proposition in the mailing list to update kernel-2.eclass with EAPI-7 compatibility?
+15:04 <juippis> did someone look at that?
+15:05 <dm0> bug #702280
+15:05 <willikins> dm0: https://bugs.gentoo.org/702280 "kernel-2.eclass: add EAPI=7 support"; Gentoo Linux, Eclasses; CONF; slyfox:kernel
+15:05 <kveremitz> yes, this was my point ..
+15:05 <Whissi> I am actually not sure if I (we) should continue that path or if we should try to migrate existing eclass to EAPI 7 following the proposed patch (which I still need to review).
+15:05 <kveremitz> we can continue "plastering over" problems..
+15:06 <juippis> Whissi: what are the faulty points in kernel-2.eclass you're trying to fix with new eclass?
+15:06 <sam_> a lot of the variables are not documented
+15:06 <kveremitz> I have a proposal for splitting unipatch function, which I would welcome review/feedback/patches (its horribly crude at present)
+15:06 <alicef> Whissi: which one is faster and reliable ?
+15:06 <kveremitz> unipatches at present uses the incorrect phase function(s)
+15:06 <Whissi> I mean, the patch looks small. I don't like the idea to keep some stuff... but when we re-invent the wheel... let's allow them to use EAPI 7 and do the other work when we have time for that. At least I won't have time for that in the next weeks.
+15:06 <Whissi> So faster would be reviewing patches for now
+15:07 <juippis> kveremitz: src_unpack instead of _prepare?
+15:07 <alicef> Whissi: I think that should be a good idea
+15:07 <kveremitz> what are the problems with not having EAPI-7 support for kernel ebuilds at present?
+15:07 <juippis> (which is hell annoying btw)
+15:07 <kveremitz> juippis: yes, basically
+15:08 <kveremitz> juippis: my version has components of unipatch in each function, for the relevant parts
+15:08 <alicef> Whissi: would be ok for you to review the current patches and add your work gradually ?
+15:09 <Whissi> yes
+15:09 <kveremitz> juippis: happy to throw the hacked version to a gist for comments/improvements/etc
+15:09 <kveremitz> ideally it needs quite a bit of work to split it more cleanly
+15:09 <kveremitz> but .. back on-topic..
+15:10 <juippis> I guess the problem with EAPI-6 is cross-compile not being consistend due to it. And some over-eager Gentoo devs have already opened a tracker bug to remove EAPI-6...
+15:10 <Whissi> :p
+15:10 <alicef> Whissi: we need a vote on that workflow ? mpagano is ok for you ?
+15:11 <mpagano> perfect
+15:11 <mpagano> +1
+15:11 <AlicefBot> +1 received from mpagano
+15:11 <alicef> wait...
+15:11 <alicef> not sure what you voted for lol
+15:11 <mpagano> the workflow
+15:11 <Whissi> He voted to send me some Easter eggs!
+15:12 <mpagano> I think the proposal was review and apply the patch from the bug, while we work in parallel on fixing it the way we want to
+15:12 <alicef> yes but there was no #vote
+15:12 <mpagano> ok
+15:12 <mpagano> -1
+15:12 <AlicefBot> -1 received from mpagano
+15:12 <alicef> so i have no idea where the bot added your vote XD
+15:12 <sam_> (It's largely a placeholder for stuff like 'eclasses don't support', rather than killing every single EAPI 6 ebuild right now.)
+15:13 <alicef> #vote eapi7 workflow of reviewing current patches from the bug and add than add whissi work gradually
+15:13 <AlicefBot> Voting still open on: GKernelCI builded and tested genpatches can be stabilized (at least writing stable on bugzilla)?
+15:13 <Whissi> +1
+15:13 <AlicefBot> +1 received from Whissi
+15:13 <alicef> #voted
+15:14 <mpagano> +1
+15:14 <AlicefBot> +1 received from mpagano
+15:14 <alicef> #vote eapi7 workflow of reviewing current patches from the bug and add than add whissi work gradually
+15:14 <AlicefBot> Voting still open on: GKernelCI builded and tested genpatches can be stabilized (at least writing stable on bugzilla)?
+15:14 <alicef> eeeh how do i close vote ...
+15:14 <alicef> #voted
+15:14 <alicef> #vote eapi7 workflow of reviewing current patches from the bug and add than add whissi work gradually
+15:14 <AlicefBot> Voting still open on: GKernelCI builded and tested genpatches can be stabilized (at least writing stable on bugzilla)?
+15:15 <alicef> #accepted
+15:15 <alicef> #accepted gkernelci
+15:15 <alicef> #accept gkernelci
+15:15 <alicef> #vote eapi7 workflow of reviewing current patches from the bug and add than add whissi work gradually
+15:15 <AlicefBot> Voting still open on: GKernelCI builded and tested genpatches can be stabilized (at least writing stable on bugzilla)?
+15:16 <alicef> #endvote
+15:16 <AlicefBot> Voting ended on: GKernelCI builded and tested genpatches can be stabilized (at least writing stable on bugzilla)?
+15:16 <AlicefBot> Votes for: 3, Votes against: 0, Abstentions: 0
+15:16 <AlicefBot> Motion carried
+15:16 <alicef> ooooh
+15:16 <alicef> #vote eapi7 workflow of reviewing current patches from the bug and add than add whissi work gradually
+15:16 <AlicefBot> Please vote on: eapi7 workflow of reviewing current patches from the bug and add than add whissi work gradually
+15:16 <AlicefBot> Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname')
+15:16 <alicef> +1
+15:16 <AlicefBot> +1 received from alicef
+15:16 <alicef> ok you can now vote :)
+15:16 <sam_> this bot is fun
+15:16 <Whissi> +1
+15:16 <AlicefBot> +1 received from Whissi
+15:17 <kveremitz> fixed :D
+15:17 * alicef first time using meetbot :/
+15:17 <kveremitz> teething issues, we'll get past it
+15:17 <alicef> mpagano you can vote now
+15:17 <kveremitz> having records will be good though
+15:17 <sam_> yeah, it's neat
+15:17 <alicef> kveremitz: that's what I hope
+15:18 <mpagano> +1
+15:18 <AlicefBot> +1 received from mpagano
+15:18 <alicef> also the log are much more simple to add to the wiki
+15:18 <alicef> actually I could do it automatically
+15:18 <kveremitz> I will hopefully get my test setup working again soon. I'm intrigued now to add lava jobs to it
+15:18 <alicef> #endvote
+15:18 <AlicefBot> Voting ended on: eapi7 workflow of reviewing current patches from the bug and add than add whissi work gradually
+15:18 <AlicefBot> Votes for: 3, Votes against: 0, Abstentions: 0
+15:18 <AlicefBot> Motion carried
+15:19 <kveremitz> ^ \\o/
+15:19 <alicef> any other discussion on eapi7 ? or we can move on?
+15:20 <alicef> ok let's move on
+15:21 <kveremitz> quick query .. are there real cross-compile issues with kernels? how are thes.. no wait, not sure I wanna know. Historically, ebuilds don't build kernels.
+15:21 <kveremitz> so this would be a New Feature.
+15:22 <dm0> Cross-compiling dist-kernels mostly works fine.  There are a couple bugs for them, though.
+15:22 <alicef> I think we finished today topics
+15:22 <alicef> anything to add ?
+15:23 <montjoie> kveremitz: use lava-docker for simple test
+15:23 <montjoie> or if you want to play I have ebuilds for it
+15:23 <alicef> or something that i forgot
+15:23 <kveremitz> montjoie: gotcha, thanks
+15:23 <alicef> mpagano: we need a vote for divide genpatches-misc form linux-patches repository ?
+15:24 <kveremitz> ^ sounds good +1 from me
+15:25 <alicef> #ACTION open space
+15:25 * AlicefBot open space
+15:25 <kveremitz> #proposal split genpatches-misc branch from linux-patches to new repo
+15:25 <alicef> i think the bot dosen't have proposal
+15:25 <alicef> #help
+15:26 <alicef> #info
+15:26 <kveremitz> I should have perhaps grokd the bot before, but we can figure this out going forward
+15:26 <alicef> mpagano ?
+15:26 <mpagano> that's fiine
+15:27 <alicef> mpagano: any other topic ?
+15:27 <mpagano> not from me
+15:27 <alicef> Whissi: any other topic ?
+15:27 <kveremitz> alicef: date of next meeting? or poll?
+15:27 <mpagano> lead election
+15:27 <alicef> you should have already got the poll
+15:28 <alicef> i think is 11/04 next meeting
+15:28 <Whissi> nope
+15:28 <alicef> lead election mail is probably tomorrow
+15:28 <mpagano> ok
+15:28 <alicef> or we can do it here ?
+15:29 <alicef> as everyone is present
+15:29 <mpagano> it's all good to me
+15:29 <Whissi> yup
+15:29 <kveremitz> alicef: where did you send it?!
+15:29 * kveremitz is losing emails or something .. >,<
+15:29 <alicef> yup do it here or yup mail ?
+15:30 <kveremitz> alas my old iee.org email is now defunct
+15:30 <kveremitz> 11/04 fine here.. 2pm UTC seems to work
+15:30 <kveremitz> somehow I had it 2pm BST here -facepalm-
+15:31 <alicef> kveremitz: I sended three reminder for meeting poll
+15:32 <alicef> kveremitz: kernel@gentoo.org and gentoo-kernel@lists.gentoo.org
+15:32 <kveremitz> really? I know you DM'd me . but only had one.... uhoh..
+15:32 <kveremitz> I wonder which alias I'm sub'd to .. :/
+15:32 <alicef> ok if there is anything else I will try to close this meeting
+15:32 <alicef> there isn't
+15:33 <kveremitz> done here
+15:33 <alicef> #save
+15:33 <alicef> #endmeeting
diff --git a/meeting_logs/2021/gentoo-kernel.2021-04-14-13.00.log.txt b/meeting_logs/2021/gentoo-kernel.2021-04-14-13.00.log.txt
new file mode 100644
index 0000000..f605259
--- /dev/null
+++ b/meeting_logs/2021/gentoo-kernel.2021-04-14-13.00.log.txt
@@ -0,0 +1,54 @@
+13:00 <alicef> #startmeeting
+13:00 <AlicefBot> Meeting started at 13:00:22 UTC.  The chair is alicef.  Information about MeetBot at https://github.com/GKernelCI/Gmeetbot
+13:00 <AlicefBot> Available commands: action, commands, idea, info, link, nick
+13:00 <alicef> #progress
+13:01 <alicef> rollcall
+13:01 <alicef> !project kernel
+13:01 <alicef> !team kernel
+13:03 <alicef> Whissi, mpagano, kveremitz
+13:04 <kveremitz> o/
+13:04 <alicef> I forgot how to use willikins
+13:04 <alicef> !help
+13:04 <willikins> alicef: help topics: 10 core modules: auth, basics, config, filters, httputil, irclog, unicode, userdata, webservice, wordlist; 28 plugins: alias, autoop, autorejoin, bans, botsnack, bugzilla, chanserv, dns, gentoo, gentoofixup, greet, karma, keywords, linkbot, math, modes, nagios, nickrecover, nickserv, note, q, quote, remind, rot, time, topic, usermodes, weather; 46 plugins ignored: use help ignored plugins to see why; 4 plugins failed
+13:04 <willikins> to load: use help failed plugins to see why (help <topic> for more info)
+13:04 <sam_> !proj kernel
+13:04 <willikins> sam_: (kernel@gentoo.org) alicef, blueness, chainsaw, mpagano, whissi, zorry
+13:04 <sam_> :)
+13:04 <sam_> so closee
+13:04 <alicef> oh thaks
+13:04 <alicef> o/
+13:04 <sam_> hmm. a few members are not in the channel
+13:05 <alicef> sam_: are you checking the away status ?
+13:07 <alicef> going on they will check later
+13:07 <alicef> #topic GkernelCI
+13:08 <alicef> I have no updates on GKernelCI development
+13:09 <alicef> I opened a bug about GKernelCI repository for mirror GKernelCI on gitweb.gentoo.org
+13:09 <alicef> but still no action
+13:09 <sam_> (I don't think any are away atm)
+13:10 <alicef> and wrote a blog about Linux Conf AU 2021 presentation on GKernelCI https://www.miraclelinux.com/tech-blog/copy_of_Linux.conf.au_Gentoo_GKernelCI_Eng
+13:10 <alicef> #topic alicef
+13:11 <alicef> other than that I opened the bug about genpatches-misc for dividing genpatches-misc from linux-patches repository
+13:12 <alicef> And also request space for kernel on project web resources host https://projects.gentoo.org/
+13:13 <alicef> for storing meeting logs in the future
+13:15 <alicef> last is not so much kernel project related but I made genchu kernel
+13:15 <alicef> -> https://github.com/genchu/genchu_kernel
+13:16 <alicef> that's everything from my side
+13:16 <alicef> probably I should use ACTION instead of TOPICS ...
+13:17 <alicef> for keeping log of each task
+13:17 <alicef> #topic eapi7
+13:18 <alicef> whissi any update on the bug review ?
+13:20 <alicef> ok lets' skip this for now
+13:21 <alicef> kveremitz: sam_: do you have any topic to discuss?
+13:21 <sam_> all good here I think, thank you for asking :)
+13:21 <alicef> #topic open topics
+13:22 <alicef> sam_: thanks :)
+13:23 <alicef> #topic election
+13:23 <kveremitz> alicef: in a Teams call .. but sorta here
+13:24 <alicef> #ACTION alicef as been renewed as kernel lead
+13:24 * AlicefBot alicef as been renewed as kernel lead
+13:25 <alicef> #topic open topics
+13:25 <alicef> kveremitz: any topics to discuss ?
+13:27 <alicef> #topic active kernel bugs
+13:28 <alicef> If we have no other topics I think that we can close the meeting
+13:28 <alicef> any objections ?
+13:30 <alicef> #endmeeting
\ No newline at end of file
diff --git a/meeting_logs/2021/gentoo-kernel.2021-07-25-13.01.log.txt b/meeting_logs/2021/gentoo-kernel.2021-07-25-13.01.log.txt
new file mode 100644
index 0000000..8a80567
--- /dev/null
+++ b/meeting_logs/2021/gentoo-kernel.2021-07-25-13.01.log.txt
@@ -0,0 +1,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
\ No newline at end of file