16:00:49 #startmeeting F34-blocker-review 16:00:49 Meeting started Mon Mar 15 16:00:49 2021 UTC. 16:00:49 This meeting is logged and archived in a public location. 16:00:49 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:49 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:49 The meeting name has been set to 'f34-blocker-review' 16:00:54 #meetingname F34-blocker-review 16:00:54 The meeting name has been set to 'f34-blocker-review' 16:01:00 #topic Roll Call 16:01:02 .hello2 16:01:03 bcotton: bcotton 'Ben Cotton' 16:01:05 ahoy to the oy, folks 16:01:09 how's everyone doing? 16:01:33 it's a monday! 16:02:00 .hello2 16:02:01 coremodule: coremodule 'Geoffrey Marr' 16:02:11 good morning! its a snowy one here in colorado 16:02:34 .hello2 16:02:35 frantisekz: frantisekz 'František Zatloukal' 16:02:37 "wintry mix" in Indiana 16:02:42 .hello jbwillia 16:02:43 Southern_Gentlem: jbwillia 'Ben Williams' 16:03:08 bcotton, that makes me think of a delicious blend of trail mix 16:03:45 .hello geraldosimiao 16:03:46 geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' 16:04:43 it's sunny here, something must be wrong 16:05:32 Cloudy and hot here in Curitiba Brazil 16:07:08 .hello pwhalen 16:07:09 pwhalen: pwhalen 'Paul Whalen' 16:07:32 .hello lruzicka 16:07:35 lruzicka[m]: lruzicka 'Lukáš Růžička' 16:07:45 * coremodule willing to act as secretary 16:07:52 thanks coremodule! 16:08:52 impending boilerplate alert 16:09:34 oh, well, first 16:09:37 #chair coremodule lruzicka 16:09:37 Current chairs: adamw coremodule lruzicka 16:09:42 #topic Introduction 16:09:47 Why are we here? 16:09:52 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 16:09:56 #info We'll be following the process outlined at: 16:10:00 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:10:04 #info The bugs up for review today are available at: 16:10:07 #link http://qa.fedoraproject.org/blockerbugs/current 16:10:12 #info The criteria for release blocking bugs can be found at: 16:10:17 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:10:21 #link https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria 16:10:27 #link https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria 16:13:06 okay, and 16:13:10 #info for Beta, we have: 16:13:20 #info 1 Proposed Blockers 16:13:20 #info 1 Accepted Blockers 16:13:25 #info 4 Proposed Freeze Exceptions 16:13:25 #info 12 Accepted Freeze Exceptions 16:13:29 #info for Final, we have: 16:13:38 #info 5 Proposed Blockers 16:13:38 #info 6 Accepted Blockers 16:13:44 #info 1 Proposed Freeze Exceptions 16:14:59 #info coremodule will secretarialize 16:15:02 let's get started with: 16:15:04 #topic proposed Beta blocker 16:15:18 #topic (1921924) Raspberry Pi 3B+ boots incredibly slow after CPU failed to come online errors 16:15:23 #link https://bugzilla.redhat.com/show_bug.cgi?id=1921924 16:15:28 #link https://pagure.io/fedora-qa/blocker-review/issue/308 16:15:32 #info Proposed Blocker, uboot-tools, MODIFIED 16:15:56 this is on our list of supported arm platforms 16:16:02 was this broken in rc1, or did we break it in rc2? 16:16:36 adamw: its been broken for a while, we didnt know the issue until recently. 16:17:01 pbrobinson was able to work it out, and do the revert for a new build 16:17:09 as far as I recall, it started with the 20210124 compose 16:17:23 or that's as far back as I tested 16:17:37 a bit of time it seems 16:19:04 how slow is "incredibly slow"? 16:19:12 5 minutes to boot 16:19:29 how long does it normally take? 16:19:36 seems like our g-i-s issue but a bit worse... 16:19:37 5 minute or longer 16:19:53 not that long... 30 seconds maybe? on a 3b+ 16:19:57 pwhalen, ^^? 16:20:09 yeah, depends on your sd card speeds I'd say 16:20:26 coremodule: sounds about right 16:20:29 something in range of 30-60 seconds afaik, on Pi 4 16:21:30 it's been slow for a while so i'm not sure if it could have been reverted a while ago 16:21:46 well the bug says more than 1 hour 16:21:47 yeah, i'm a bit fence-y about this one 16:21:56 seems a bit hard to take it when we didn't actually take the g-i-s one as a blocker 16:22:14 yeah, i was just thinking the same thing 16:22:18 if it's 5 minutes, CommonBugs and move on - but I'd consider a 0Day which is what I suggested in the blocker-review issue 16:22:43 +1 16:22:55 yea, Its never taken an hour to boot for me nor would I have the patience if it did 16:23:02 haha 16:23:55 i don't think this is what 0day blockers are meant for 16:24:17 a bug's a 0day blocker if it's a blocker, but the fix for it doesn't need to go on media 16:24:23 that's not really what this is 16:24:40 ok if it's not a blocker then BetaFE so it can go to stable and upgraders don't hit it 16:24:40 i think we can give it +1 FE though? 16:25:32 (I still feel we should do an rc1.3 with new shim/grub so this could get pulled in too, but that can be discussed later ofc) 16:25:33 cmurf but installers do 16:25:47 -1 Blocker +1 FE 16:25:49 -1 blocker, +1 FE in case there's a new RC 16:25:53 -1 blocker +1 FE 16:25:56 yeah but it's just slow, not broken 16:25:58 frantisekz: is the new shim already registered? 16:26:04 -1 Blocker, +1 FE 16:26:05 hey no spoilers 16:26:07 -1 blocker, +1 FE 16:26:08 -1 BB +1 FE 16:26:09 -1 blocker +fe 16:26:09 :D 16:26:39 shim/grub is not going to be ready for beta... 16:26:41 lruzicka: in upstream, yes, not in dist-git yet :/ 16:26:58 proposed #agreed 1921924 - RejectedBlocker AcceptedFreezeException (Beta) - as the system does boot eventually this doesn't seem to break the criteria, and there's the precedent of the g-i-s issue we didn't block on either. But accepted as an FE as it's obvious highly inconvenient and can't be fixed entirely with an update 16:27:03 -1 blocker. +1 FE 16:27:04 ack 16:27:07 ack 16:27:08 ack 16:27:08 ack 16:27:11 ack 16:27:14 Ack 16:27:44 ack 16:27:45 ack 16:28:26 #agreed 1921924 - RejectedBlocker AcceptedFreezeException (Beta) - as the system does boot eventually this doesn't seem to break the criteria, and there's the precedent of the g-i-s issue we didn't block on either. But accepted as an FE as it's obvious highly inconvenient and can't be fixed entirely with an update 16:28:43 so, uh, there are no more proposed Beta blockers. if someone wants to talk about doing another RC, please propose another beta blocker sharpish 16:28:50 because there won't be another RC unless there's a blocker :D 16:28:58 we need kparal 16:29:07 adamw, but those poor FEs!!! :D 16:29:11 1938630 is proposed as a Final blocker, not a Beta blocker 16:29:17 does someone think it should block Beta? 16:29:36 Vacation time 16:29:57 no, I don't think we should block beta on this 16:31:09 okay then 16:31:17 so that means rc2 is still on track for release 16:31:19 moving on to: 16:31:24 #topic proposed Beta freeze exception issues 16:31:47 (we'll vote on these in case a blocker is discovered later) 16:31:53 #topic (1936147) bcm283x-firmware update breaks booting on Raspberry Pi 3B+ 16:31:58 #link https://bugzilla.redhat.com/show_bug.cgi?id=1936147 16:32:04 #link https://pagure.io/fedora-qa/blocker-review/issue/309 16:32:07 #info Proposed Freeze Exceptions, bcm283x-firmware, MODIFIED 16:32:30 +1 fe 16:32:36 +1FE, seems difficult for it to get worse :P 16:32:52 +1FE 16:33:16 oh 16:33:25 why does it need an FE? 16:33:34 it never got to stable updates, as adamw said in the ticket 16:34:22 and without the fe it wont 16:35:04 +1Fe 16:35:06 I mean, the issue was caused by something that didn't leave updates-testing 16:35:12 if I udnerstand it correctly? 16:35:36 +1 FE 16:35:45 yeah, that's the question i have 16:35:55 something in stable is borked as well in that case 16:35:56 i'd be +1 to the issue if it was actually broken in stable, but if it isn't, an FE is pointless 16:36:09 that's a good point 16:36:16 it looks like it's been obsoleted anyway 16:36:21 https://bodhi.fedoraproject.org/updates/FEDORA-2021-84510c6f65 16:36:44 punt and ask for more info 16:36:57 i think peter may have just proposed this as a kind of proxy for wanting the 'improvements' pushed, but if so i'd prefer a better proposal :D 16:38:54 have there been more FE's this cycle? or am i on crazy pills? 16:39:04 it does seem like it 16:39:15 both? :D 16:39:21 fewer blockers though, which is nice 16:39:27 cmurf: yes ;-) 16:40:18 i don't think it's just you 16:40:21 anyhoo, i agree with punt 16:40:29 +1 punt, i change my vote 16:40:56 +1 punt 16:41:22 punt means it will not get into Beta anyway, right? 16:41:27 +1 punt 16:41:40 lruzicka, it might, we can vote in ticket before the beta, imo 16:41:42 lruzicka[m], it wont if its not in rc2 16:41:52 lruzicka: right now it wouldn't anyway since there's no blockers in rc2 16:42:00 if we actually do need an rc3 i can check back in on this one before we build it 16:42:13 ok, so +1 punt 16:42:34 Ok +1 punt 16:44:02 proposed #agreed 1936147 - punt (delay decision) - the bug proposed seems to be present only in updates-testing, so an FE is unnecessary. We'll ask Peter if he really wanted an FE for other improvements in the update, and reconsider if so 16:44:40 ack 16:44:40 ack 16:44:41 ack 16:44:49 ack 16:44:58 #agreed 1936147 - punt (delay decision) - the bug proposed seems to be present only in updates-testing, so an FE is unnecessary. We'll ask Peter if he really wanted an FE for other improvements in the update, and reconsider if so 16:45:22 #topic (1925571) F34FailsToInstall: gr-hpsdr 16:45:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=1925571 16:45:34 #link https://pagure.io/fedora-qa/blocker-review/issue/291 16:45:36 #info Proposed Freeze Exceptions, gr-hpsdr, ON_QA 16:45:43 as noted in the issue, +1 on the precedent from the other similar issues 16:45:58 +1 FE 16:46:08 sure +1 fe 16:46:17 +1fe 16:46:31 +1 FE 16:47:10 +1 Fe 16:47:37 proposed #agreed 1925571 - AcceptedFreezeException (Beta) - FE granted on precedent that we allow FEs for failstoinstall bugs to aid upgrade experience, if the fix looks safe 16:47:46 ack 16:47:47 ack 16:47:50 ack 16:48:01 ack 16:48:57 #agreed 1925571 - AcceptedFreezeException (Beta) - FE granted on precedent that we allow FEs for failstoinstall bugs to aid upgrade experience, if the fix looks safe 16:49:08 ack 16:49:14 late ack 16:49:24 #topic (1938598) push grub2-2.04-39.fc34 to stable 16:49:24 unnecessary ack 16:49:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=1938598 16:49:33 .fire cmurf excessive ack 16:49:33 adamw fires cmurf excessive ack 16:49:40 #link https://pagure.io/fedora-qa/blocker-review/issue/307 16:49:43 #info Proposed Freeze Exceptions, grub2, NEW 16:49:49 hurray! 16:49:54 * cmurf leaves 16:49:58 j/k 16:50:42 i do not know why -36 version of grub that had this functionality, and was stable already at the time of freeze, did not make it into any composes 16:51:24 but setting that aside, i think either -37 or -39 should be pushed to stable now for system-upgrades, it doesn't need to be on media 16:52:34 I am running -39 and have not experienced any issues so far. 16:52:57 the only change between -37 and -39 applies to ppc 16:53:43 so, does anaconda ensures the exactly same result for -35? I am no grub expert, just curious if we're testing something that would be the part of final 16:54:24 i don't think this really needs an FE, if the update's queued for stable it'll get pushed stable shortly before beta release anyhow 16:54:27 we should get enough testing 16:54:51 * Southern_Gentlem is now confused if this should be removed per cmurf comment 16:55:18 -FE 16:55:49 -1 FE 16:57:41 if there's no FE, that means we're testing system-upgrades with the wrong grub version 16:58:17 cmurf, but once beta is released it can roll in anyways 16:58:18 when to mirrors show it as stable? 16:58:27 when ^do mirrors 16:58:44 will it be day 1? or could it be delayed/ 16:59:07 the intent of the feature was to do the conversion during the offline upgrade, not as an update 16:59:14 it should work as an update but... it's riskier 16:59:19 cmurf make up your mind you were argueing against it now you are agruing for it 16:59:37 "if the update's queued for stable it'll get pushed stable shortly before beta release anyhow" 16:59:42 quoth me 16:59:45 at this point it i will not be in rc2 16:59:52 doesn't need to be in rc2 17:00:04 then its doesnt need a FE 17:00:26 needed for system-upgrades 17:00:49 like no one is testing -39 for f32/f33 upgrades unless you manually enable u-t when doing dnf system-upgrade 17:01:07 i'm not even sure how to get gnome-software/pk to use u-t on a system upgrade 17:01:51 adamw, am I wrong on my thinking ? 17:02:18 cmurf, and it should be there in f34 -release yes 17:02:33 it wont be in beta at this point in time 17:02:39 cmurf: the point is 17:02:50 this does not need an fe for people upgrading around beta release to get it 17:02:57 it will be in stable on or around releaes day 17:03:08 Southern_Gentlem: doesn't matter, anaconda is what creates the stub grub.cfg on the ESP on new clean installs; and it's a script in the grub package for upgrades that does it 17:03:11 we only need FEs if we really want it stable before Beta release goes out 17:03:23 also at this point i'm not going to request stable pushes for anything that's not in RC2 anyway 17:03:29 unless we wind up doing an RC3 17:05:14 ok 17:05:16 i mean, i could be +1 in principle i guess, it just won't make a whole lot of difference either way :D 17:06:29 so in conclusion, i vote ¯_(ツ)_/¯ 17:06:41 +1 ¯_(ツ)_/¯ 17:06:42 +1 ¯_(ツ)_/¯ 17:07:50 if it doesn't matter at all then just leave it alone, but what if someone doing system-upgrade testing between now and next tuesday finds a problem? :) 17:07:55 -1 FE if i have to mak ea real vot,e i guess 17:08:00 like if we don't want that to happen, -1 FE haha 17:08:44 I'm confused what we want here 17:08:51 hey there are missing limbs in those shrugs! 17:08:53 but I could go either way, so +1? 17:09:12 cmurf: the \ got mysteriously lost when i pasted 17:09:54 everyone is confused what we want so I suggest just leaving it alone if it's not compelling enough to FE 17:10:04 okay so in the interests of voting something, i'm gonna say -1 FE i think, because this isn't "we want to fix something in upgrades", it's "we want to change what upgrades do and see if it breaks". 17:11:28 it's both, but ok 17:12:12 -1 FE then :) 17:12:16 -1 FE 17:13:13 proposed #agreed 1938598 - RejectedFreezeException (Beta) - this is rejected as it's not a clear bug fix but more of a "change the behaviour and see what happens". In practice it will likely get pushed stable at the same time either way anyway 17:13:23 ack 17:13:27 ack 17:13:30 ack 17:13:47 ack 17:15:40 #agreed 1938598 - RejectedFreezeException (Beta) - this is rejected as it's not a clear bug fix but more of a "change the behaviour and see what happens". In practice it will likely get pushed stable at the same time either way anyway 17:15:45 #topic (1923463) kiwi-boxed-plugin: FTBFS in Fedora rawhide/f34 17:15:45 Ack 17:15:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=1923463 17:15:50 #link https://pagure.io/fedora-qa/blocker-review/issue/288 17:15:51 #info Proposed Freeze Exceptions, kiwi-boxed-plugin, ON_QA 17:16:15 +1 FE 17:16:25 meh 17:16:56 yeah, whatevs, we usually accept these 17:17:05 again it's not going to make much practical difference 17:17:07 +1 17:17:33 +1 FE 17:17:35 (less mess on https://packager-dashboard.fedoraproject.org/ if nothing else :D ) 17:18:26 proposed #agreed 1923463 - AcceptedFreezeException (Beta) - this is accepted on the principle we usually grant FEs to FTBFS bugs, though in practice it won't be pushed stable unless there's another RC 17:18:27 ack 17:18:30 yes, crushing my FTBFS and FTIs has been something I"m trying to do 17:18:31 ack 17:18:58 usually I wind up having to do this after freeze because that's when the feature dev is done 17:19:00 ack 17:19:06 it's kind of unfortunate, but ehh 17:19:38 #agreed 1923463 - AcceptedFreezeException (Beta) - this is accepted on the principle we usually grant FEs to FTBFS bugs, though in practice it won't be pushed stable unless there's another RC 17:19:52 ok, moving onto: 17:19:55 #topic proposed Final blockers 17:20:12 #topic (1937783) Abrt does not catch a simulated segfault. 17:20:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1937783 17:20:14 #link https://pagure.io/fedora-qa/blocker-review/issue/300 17:20:19 #info Proposed Blocker, abrt, NEW 17:21:25 No simulated catch, no real catch, I think 17:21:27 "Failed to rename ‘/home/lruzicka/.abrt/spool’ to ‘/home/lruzicka/.cache/abrt/spool’" seems like the issue to me... 17:22:28 ok, I guess it is still not my fault, is it? 17:22:40 probably not 17:23:17 the thing is, I was having quite a lot of catches and now I am not having any :D 17:23:56 by lot I mean like 3 a day or so 17:24:24 would help to know what changed when it broke, i guess 17:24:39 +1 punt, needinfo 17:24:55 i'm -1 on the crash notifications criterion, because this bug can't possibly make notifications of crashes more likely to appear :D 17:25:07 could possibly buy default application functionality for a dollar, though 17:25:10 7 17:25:19 +1 punt 17:25:25 but i would like more data/someone else to confirm 17:25:53 I just want to say that a fresh install VM did the same 17:26:09 I would be glad if someone else tried too 17:27:52 same issue with enforcing=0? 17:28:07 let me check 17:28:09 still have a metric f ton of avc's to sort out 17:28:55 yes, that with permissive mode it works 17:29:38 i wanna know how you tested that inside of 50 seconds :P i need to start using your process 17:30:39 +1 punt 17:31:05 setenforce 0 17:31:07 lruz: aha, so look for an selinux denial, i guess... 17:31:12 will_segfault 17:31:18 abrt reported crash 17:32:08 ok so yeah if it turns out it's being blocked by selinux i'll be +1 final blocker because it needs to work, qualifies as "entirely non-functional" 17:34:03 proposed #agreed 1937783 - punt (delay decision) - this looks like a potential blocker, but we'd like to gather more data and have other testers confirm before deciding 17:34:21 ack 17:34:23 ack 17:34:28 ack 17:34:52 ack 17:35:05 #agreed 1937783 - punt (delay decision) - this looks like a potential blocker, but we'd like to gather more data and have other testers confirm before deciding 17:35:11 #topic (1937308) First login attempt fails on laptop with fingerprint reader 17:35:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=1937308 17:35:23 #link https://pagure.io/fedora-qa/blocker-review/issue/296 17:35:28 #info Proposed Blocker, gdm, VERIFIED 17:35:43 so this is confirmed fixed in beta so i propose we don't waste too much time on it 17:35:56 if we don't have a clear consensus right away let's just punt and it'll go away 17:36:27 ack 17:36:32 +1 punt 17:36:42 +1 punt 17:37:35 +1 punt 17:38:29 proposed #agreed 1937308 - punt (delay decision) - this isn't a completely clear call for Final blocker, so since it's confirmed fixed in Beta anyway we're just going to duck it by waiting for that fix to be pushed stable 17:39:09 ackingly ack 17:40:36 any more acks 17:40:38 ack 17:41:30 ack 17:41:51 ack 17:42:16 #agreed 1937308 - punt (delay decision) - this isn't a completely clear call for Final blocker, so since it's confirmed fixed in Beta anyway we're just going to duck it by waiting for that fix to be pushed stable 17:42:24 #topic (1936935) Gnome Software does not update correctly to the current status. 17:42:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=1936935 17:42:32 #link https://pagure.io/fedora-qa/blocker-review/issue/293 17:42:37 #info Proposed Blocker, gnome-software, NEW 17:43:43 -1 blocker, it's a bug but not entirely non-functional 17:43:53 well.. ha if you can't remove things hmm 17:44:20 you can, it only seems like they are not removed when they actually are 17:44:27 after reboot, the status is shown correctly 17:44:36 ahh so it's a cosmetic bug 17:44:42 and it is always just the first packagt 17:44:44 package 17:44:59 -1 Blocker, imo 17:44:59 that's cute 17:45:10 so, basically, you are not very likely to arrive into it, because who uninstalls a package right after it has been installed .... 17:46:03 a tester does, I think ... or if you are totally disappointed by the application. 17:46:18 i think this would fail the last blocker test 17:46:30 on the whole the critical functions work 17:46:30 which does not happe too often ... I proposed it for discussion purposes :D 17:49:08 so, -1 17:49:10 any other votes? 17:49:40 -1 also 17:49:57 -1 FB +1 FE 17:50:37 -1 Blocker, as said above 17:52:24 proposed #agreed 1936935 - RejectedBlocker (Final) - this doesn't seem to constitute a criterion violation, the essential functions work, and the sync issue is transient (solved with a reboot) 17:52:24 ack 17:52:25 ack 17:53:22 -1/ack 17:53:46 ack 17:54:07 ack 17:54:31 #agreed 1936935 - RejectedBlocker (Final) - this doesn't seem to constitute a criterion violation, the essential functions work, and the sync issue is transient (solved with a reboot) 17:55:18 #topic (1924908) Long delay before GNOME Initial Setup runs on first boot, "Oops, something went wrong" screen visible at times 17:55:22 #link https://bugzilla.redhat.com/show_bug.cgi?id=1924908 17:55:26 #link https://pagure.io/fedora-qa/blocker-review/issue/240 17:55:31 #info Proposed Blocker, mutter, VERIFIED 17:55:38 again, verified fixed in beta so no need to waste too much time on ti 17:56:11 +1 skip/punt/¯\_(ツ)_/¯ 17:58:19 +1 Final blocker 17:58:23 ugly 17:58:44 oh, verified already 17:58:52 +1 forget 17:59:27 to the memory hole! 17:59:55 proposed #agreed 1924908 - punt (delay decision) - again this isn't a completely clear call, and the fix is verified in Beta, so we will just punt to avoid having to think too hard about it 18:00:04 ack 18:00:05 ack 18:00:19 ack 18:00:22 and we haven't talked about the proposed release criterion yet 18:00:43 so yea ack punt ack 18:01:14 #agreed 1924908 - punt (delay decision) - again this isn't a completely clear call, and the fix is verified in Beta, so we will just punt to avoid having to think too hard about it 18:01:15 ack 18:01:43 alright, looks like that's everything 18:01:46 #topic Open floor 18:01:54 please test and karma the updates from Beta so we can push them stable, folks 18:02:11 all the ones in https://pagure.io/releng/issue/10056#comment-720933 18:04:20 did i miss the shim final blocker proposal? 18:04:51 i don't see it 18:05:09 any other business? anyone have concerns about beta or rc2 that weren't captured? 18:05:27 oh i guess it was decided in the blocker-review app 18:07:43 thanks adamw for leading the meeting and others for attending 18:07:51 see ya on thursday! 18:10:47 oops 18:11:09 quick assign something to adam! 18:11:25 is anyone else chair and can end the meeting? 18:11:39 #endmeeting 18:11:45 not me 18:11:52 was there a netsplit? 18:11:54 #endmeeting 18:12:03 me neither... 18:12:09 coremodule? 18:12:15 i dont think so... 18:12:17 #endmeeting