15:01:15 <adamw> #startmeeting Fedora QA meeting 15:01:15 <zodbot> Meeting started Mon Sep 15 15:01:15 2014 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:18 <adamw> #meetingname fedora-qa 15:01:18 <zodbot> The meeting name has been set to 'fedora-qa' 15:01:20 <RogerB_TX> ok. what is pirates pad and how does that work? 15:01:26 <adamw> #topic Roll call 15:01:36 <RogerB_TX> ooops. gone. 15:01:45 * adamw rogerb_tx all Fedora 21 testing 15:01:48 <adamw> aww. 15:01:59 * Guest40696 is here 15:02:00 * jreznik is here, will have to leave although 15:02:01 <amita> hi adamw 15:02:52 * amita is here 15:02:55 * pwhalen_ is here 15:02:59 * brunowolff is here 15:03:31 * roshi is here 15:04:58 <adamw> #chair brunowolff pwhalen_ 15:04:58 <zodbot> Current chairs: adamw brunowolff pwhalen_ 15:05:49 <adamw> morning folks, thanks for coming 15:06:41 * tflink shows up a few minutes late 15:06:56 <adamw> .fire tflink 15:06:56 <zodbot> adamw fires tflink 15:07:03 <adamw> (hey, it's been a while) 15:07:28 <tflink> .fire adamw for not using a reason for the firing 15:07:28 <zodbot> adamw fires adamw for not using a reason for the firing 15:07:30 <tflink> :-P 15:08:25 <adamw> .fire tflink for insubordination 15:08:26 <zodbot> adamw fires tflink for insubordination 15:08:38 <adamw> #topic Previous meeting follow-up 15:08:48 <tflink> that's better :) 15:08:59 <adamw> #info "adamw to try and expedite discussion of the OS X / Windows multiboot criteria revision" - so we didn't quite finish that off this week, but i'm hoping we can get to it later in the meeting 15:09:25 <adamw> #info "adamw to file and marked as approvedFE the GNOME 3.13.91 bug" - in the end it was marked as fixing a couple of other bugs that were already FEs, so we pushed it for those, with a note of why we were taking a mega-update 15:09:42 <adamw> any other followups for non-action items or anything? 15:11:45 <adamw> okey dokey 15:11:56 <adamw> #topic Fedora 21 status 15:12:44 <adamw> so, TC7 is out and we have some initial results, looks like we didn't find new bugs compared to TC6 yet 15:13:03 <jreznik> that's good to hear 15:13:21 <adamw> looks like no-one's formally re-tested https://bugzilla.redhat.com/show_bug.cgi?id=1139015 yet (the workstation corrupt compose bug) 15:13:33 <adamw> so we should check that today 15:16:05 <roshi> I can check that today 15:16:35 <brunowolff> You know that looks like the squashfs issue I was going to bring up later in the meeting. 15:17:37 <brunowolff> The fact that the issue was with the last thing in the file system would be an odd coincidence if it was a different issue. 15:17:37 <adamw> yeah, that's what I was thinking 15:17:46 <adamw> I actually pinged dgilmore about it last night 15:17:50 <adamw> that's why I put it on the agenda :) 15:17:57 <adamw> but since you borught it up...dgilmore, are you around? 15:18:13 <dgilmore> adamw: i suspect it could be the cause. I do not think we are that big though 15:18:47 <dgilmore> program.INFO: Running... mksquashfs /tmp/work/Server/x86_64/installroot/images/runtime-workdir /tmp/work/Server/x86_64/installroot/images/install.img -comp xz -Xbcj x86 15:18:49 <brunowolff> It's the size of the ext file system not the squashed image. The underlying file system is over 6 GB. 15:18:50 <dgilmore> program.INFO: Parallel mksquashfs: Using 8 processors 15:18:53 <dgilmore> program.INFO: Creating 4.0 filesystem on /tmp/work/Server/x86_64/installroot/images/install.img, block size 131072. 15:18:56 <dgilmore> program.INFO: ^M[=========================================\ ] 11500/16384 70%^M[================================================| ] 13500/16384 82%^M[===========================================================-] 16384/16384 100% 15:18:58 <brunowolff> I checked on that yesterday. 15:19:01 <dgilmore> program.INFO: 15:19:03 <dgilmore> program.INFO: Exportable Squashfs 4.0 filesystem, xz compressed, data block size 131072 15:19:07 <dgilmore> program.INFO: compressed data, compressed metadata, compressed fragments, compressed xattrs 15:19:10 <dgilmore> program.INFO: duplicates are removed 15:19:13 <dgilmore> program.INFO: Filesystem size 280010.71 Kbytes (273.45 Mbytes) 15:19:15 <dgilmore> program.INFO: 13.35% of uncompressed filesystem size (2097216.44 Kbytes) 15:19:19 <dgilmore> brunowolff: okay, its likely the cause then 15:20:21 <brunowolff> There is a build with the fix for this requested for testing. 15:21:04 <adamw> OK 15:21:07 <brunowolff> I am seeing a problem with LZ4, but it isn't used for images and is intermittent and likely was already present and I just hadn't seen it before. 15:21:27 <adamw> so can you mark the update as fixing https://bugzilla.redhat.com/show_bug.cgi?id=1139015 ? 15:21:39 <brunowolff> So I think we probably want to try to use the build with the fix. 15:21:49 <adamw> yeah, i think so too 15:22:01 <adamw> someone mentioned in a post on test@ (I think) that they'd hit 'pane is dead' on some nightlies 15:22:14 <brunowolff> Can I do that based on our best guess rather than an actual test? 15:22:19 <adamw> so it looks like it wasn't just a one off (unless that's a different bug) 15:22:25 <adamw> brunowolff: THIS IS FEDORAAAAAAAAAAAAAAAAAAAAAAAAA 15:22:31 <adamw> (so of course you can, it's what we do around here. :>) 15:22:42 <adamw> testing, pish posh. 15:22:47 <brunowolff> OK, I update the koji request for f21. 15:22:55 <adamw> bodhi 15:23:13 <brunowolff> I was about to say I mean bohdi. 15:23:50 <jreznik> brunowolff: everybody understood it, it's adamw :) 15:24:00 <adamw> *sobs* 15:24:40 <jreznik> so this means another tc build with this fix, rigth? 15:25:23 <dgilmore> jreznik: or an RC 15:25:33 <dgilmore> if we think we have fixes for everything 15:26:07 <adamw> #action brunowolff to mark https://admin.fedoraproject.org/updates/squashfs-tools-4.3-8.fc21 as fixing blocker bug #1139015 15:26:14 <adamw> so, on that topic 15:26:32 <adamw> unfortunately we still have a rather big hairy problem in TC7: network install still doesn't work as intended, and the reasons why are somewhat intractable 15:26:57 <dgilmore> adamw: and no clear good way to fix it 15:27:18 <adamw> right, i was using a five dollar word for the same thing. :P 15:27:26 <jreznik> well, I think we're getting close to the point to fudge productized netinst for Alpha or next year release :( 15:27:37 <adamw> yeah, i concur 15:27:45 <kparal> ouch, sorry, I forgot about the meeting 15:27:45 <dgilmore> it will work great, so long as you do not enable updates 15:27:46 <roshi> that's what it seems like 15:27:52 * jreznik learned a new english word - intractable 15:27:54 <dgilmore> and tell it to use the product tree 15:28:02 <adamw> so I did a write-up of the current situation in https://bugzilla.redhat.com/show_bug.cgi?id=1134524#c24 and https://bugzilla.redhat.com/show_bug.cgi?id=1134524#c25 15:28:35 <adamw> dgilmore: updates-testing.repo is enabled by default, though, and we can't really change that as it's desired for the installed system 15:28:54 <adamw> #info network install still does not work as intended, explain in https://bugzilla.redhat.com/show_bug.cgi?id=1134524#c24 and #c25 15:29:15 <dgilmore> adamw: right 15:29:16 <brunowolff> The squashfs update request is now tied to bug 1139015. 15:29:49 <jreznik> thanks brunowolff 15:30:59 <adamw> so there's an 'easy' problem and a 'hard' problem, both of which ultimately lead to anaconda getting data for all the package groups, not seeing just the groups for the Product as we want 15:31:37 <adamw> the 'easy' problem is that if fedora.repo is on the install image and enabled, anaconda will use it as a supplementary repo by default, and get the package group data there. there are various ways we possibly could avoid that, all a bit messy, but doable 15:32:11 <adamw> the 'hard' problem is that it will also use updates-testing.repo as a supplementary repo, and that has package group data too, so even if we somehow get fedora.repo out of Product netinsts, they'll get group data from updates-testing, which is harder to solve. 15:34:30 <roshi> fun times :-/ 15:34:31 <adamw> i suspect we're all kinda reaching the point where we feel like we should sit down and take a proper look at it instead of whacking in any more quick fixes...so we come to the 'is it ok to ship alpha with no / broken netinsts' question 15:34:52 <adamw> i believe fesco considered it somewhat last week, and it's probably going to come up again 15:35:09 <roshi> probably 15:35:26 <adamw> anyone have thoughts on that? 15:35:59 <roshi> if we don't ship it with alpha, what are teh chances it doesn't make beta as well? 15:36:00 <danofsatx> dammit, why am I late? 15:36:20 <kparal> I've haven't been here from start, but does 'broken' mean "can't install", or "offers all environments, not just the single one"? 15:36:58 <adamw> kparal: 'offers all environments, not just the product one' 15:37:11 <adamw> well, i think tc7 just fails again, but we could fairly easily reach the 'offers all environments' state 15:37:19 <adamw> we'd effectively have a universal netinst 'by mistake 15:37:27 <kparal> if that's the only problem, and it can install, I don't see it as something that should block Alpha 15:38:01 <adamw> it may well not, according to the blocker list, it's been kind of a Fedora.next 'product design' thing 15:38:01 <roshi> personally, I like a netinst that lets you install all the things 15:38:07 <adamw> maybe we can look at it that way? 15:38:25 <adamw> if TC8/RC1 acts as a 'universal' installer, QA says 'not a blocker per se' and fesco discusses whether they mind? 15:38:40 <jreznik> from schedule perspective, more slips would lead to next year fedora... 15:38:51 <kparal> from QA perspective, you can install the product you want, so I don't see it as a bug per se 15:38:59 <roshi> that sounds good to me adamw, kparal 15:39:16 <roshi> but then again, I've wanted a universal netinst to begin with :p 15:39:23 <kparal> +1 to that 15:39:27 <adamw> heh 15:39:33 <adamw> RESOLVED NOTOURPROBLEM 15:39:48 <roshi> cuts down on the things to test 15:40:04 <jreznik> we're already on 2014-12-02 with GA, so the question is if we will be hit more by non-next neinstall or no .next products this year :) 15:40:22 * adamw looks on the QA team's willingness to come up with creative fudges, sheds a proud tear 15:40:27 <adamw> ahh, our babies grow up so fast 15:40:36 <sgallagh> jreznik: I've just sent an email to FESCo requesting votes on a change to the Freeze policy. 15:40:40 <roshi> lol 15:41:07 <sgallagh> Basically, I'm advocating for the Beta Freeze to last all the way to GA, so that nothing goes into Final without the blocker/FE process. 15:41:08 <jreznik> sgallagh: ? 15:41:31 <sgallagh> With the hopes of avoiding further slippage 15:41:33 <jreznik> sgallagh: why? but can we talk about it later? let's solve this one 15:41:47 <adamw> yeah, seems somewhat orthogonal, though it sounds like we have a plan here 15:41:50 <jreznik> first, what to do with Alpha - it's more about slipage 15:42:05 <brunowolff> Please don't do that. 15:42:21 <adamw> roshi: to pick up your question from earlier, i don't think not having product-ized netinst in alpha makes it much more or less likely we'll still have trouble at beta 15:42:35 <adamw> roshi: we very well *might*, but i don't think whether we include it with alpha changes the calculation much 15:42:52 <danofsatx> adamw: translation? too many double (triple?) negatives in that sentence 15:42:53 <adamw> so, let's see 15:42:56 <roshi> well, I just mean the whole "Well, we fudged this before, why not now?" door that fudging opens up 15:43:10 <adamw> danofsatx: roshi asked if not including product-ized netinst in alpha gives us a higher risk of not including it in beta 15:43:27 <adamw> roshi: that's a reasonable point; i'd suggest fesco makes a clear call on whether we have a hard block on it for beta 15:43:38 <adamw> we can check the criteria line up with the policy at that point 15:43:42 <roshi> that's the only thing I thought about 15:43:45 <adamw> jreznik: sgallagh: how's that sound? 15:44:00 <sgallagh> As the person who advocated for that case in the first place, it sounds fine :) 15:44:11 <jreznik> adamw: sounds good to me. also we want WGs to make the call, not only FESCo 15:44:11 <sgallagh> (Non-blocking for *this* Alpha, blocking for Beta) 15:44:34 <sgallagh> jreznik: I think this is FESCo-level. It's about the delivery and perception of Fedora as a whole 15:44:45 <sgallagh> We'll listen to their input, of course 15:44:52 <sgallagh> But the decision should be FESCo's 15:45:20 <adamw> +1 15:45:27 <jreznik> adamw: so, do we need to revert any of the changes that were made for this bug or are we ok? 15:45:48 <adamw> jreznik: i believe we can make universal netinst work just by ensuring fedora-repos-anaconda shows up on the next compose 15:46:09 <adamw> we muffed that for tc7, i sent a patch for lorax for tc8/rc1, i'll have to check the status of that 15:46:28 <jreznik> ok 15:47:41 <adamw> propose #agreed QA will say that in principle a network install image which offers all environments does not violate Alpha criteria (hence can be signed off from QA perspective), it is FESCo's decision whether Product-ized netinst is required to be in shape for Alpha as part of Fedora.next product design 15:48:09 <roshi> ack 15:48:16 <kparal> ack 15:48:21 <tflink> ack 15:49:43 <jreznik> we talked about Beta, no? for FESCo decision 15:49:56 <jreznik> so patch 15:50:04 <adamw> sure... 15:50:10 <adamw> propose #agreed QA will say that in principle a network install image which offers all environments does not violate Alpha criteria (hence can be signed off from QA perspective), it is FESCo's decision whether Product-ized netinst is required to be in shape for Alpha and/or Beta as part of Fedora.next product design 15:50:16 <roshi> I thought that was going to be another proposed #agreed 15:50:18 <roshi> lol 15:50:25 <roshi> ack 15:50:45 <jreznik> still not sure it's what we agreed above - fudge for Alpha, ask FESCo for Beta 15:51:34 <roshi> I thought we agreed that fesco had to decide, but QA, *right now* could say no criteria were violated 15:51:49 <roshi> which is basically what's in the #agreed 15:53:34 <adamw> i'm reserving fesco the right to say 'but we want it in alpha' 15:53:40 <adamw> i doubt they will, but they can make that call if they like 15:54:25 <jreznik> I'm ok with that, I just understood discussion above in the different way 15:54:47 <jreznik> sgallagh: could you help here to make sure it goes through fesco as quickly as possible? 15:54:56 * jreznik is ack 15:55:01 <kparal> ack 15:55:03 <sgallagh> Sorry, I am in multiple meetings. Reading scrollback now 15:55:50 <adamw> jreznik: i don't think the QA meeting can decide that we *will* fudge it for alpha, just that QA is fine with doing that. 15:55:59 <adamw> fesco always can step in and say 'no, it's gotta be fixed.' 15:56:02 <sgallagh> OK, I'll try to get an out-of-band decision made on that. 15:56:10 <sgallagh> (i.e. before Wednesday's meeting) 15:56:18 <adamw> thanks 15:56:24 <adamw> #agreed QA will say that in principle a network install image which offers all environments does not violate Alpha criteria (hence can be signed off from QA perspective), it is FESCo's decision whether Product-ized netinst is required to be in shape for Alpha and/or Beta as part of Fedora.next product design 15:56:38 <jreznik> sgallagh: thanks! I'd like to avoid ticket -> meetings delays 15:56:53 <adamw> #action sgallagh to run the netinst question by fesco ASAP 15:57:05 <sgallagh> Well, I'll file it as a ticket, but I'll try to force people to reply quickly 15:57:31 <jreznik> sgallagh: yeah, of course I mean ticket should be written - I'll comment there what does it mean from schedule perspective 15:57:47 <sgallagh> ok 15:58:22 <adamw> aaand we're running up on the hour again, yeesh 15:58:31 <adamw> shall we do the multiboot criteria quickly? 15:58:37 <jreznik> ok, do you have ticket for that freeze policy change or place where it was discussed? 16:03:12 <jreznik> sgallagh: ^^^ 16:03:13 <adamw> seems we're running out of juice, so let's wrap up 16:03:22 <adamw> the multiboot discussion keeps spawning new threads anyhow 16:03:32 <adamw> #topic Open floor 16:03:35 <roshi> yay for threadspawn! 16:03:38 <adamw> did I miss anything aside from multiboot? 16:03:47 <roshi> cockpit test day? 16:03:51 <roshi> is that happening today? 16:03:51 <adamw> that's this week? 16:03:56 <kparal> tomorrow 16:03:57 <adamw> today? yaay for organization 16:04:09 <roshi> I thought it was the 15th... 16:04:12 <adamw> roshi: i thought you were supposed to know :) 16:04:21 <kparal> calendar says tomorrow 16:04:26 <kparal> I just sent the announcement 16:04:36 <roshi> looking at fedocal it's today through tomorrow for me 16:04:36 <kparal> pschindl created the live images 16:04:36 <roshi> ok, that works 16:04:36 <adamw> https://fedoraproject.org/wiki/Test_Day:2014-09-16_Cockpit says 09_16 . 16:04:38 <roshi> sweet then 16:04:42 <adamw> #info cockpit test day is tomorrow 16:04:47 <adamw> #undo 16:04:47 <zodbot> Removing item from minutes: INFO by adamw at 16:04:42 : cockpit test day is tomorrow 16:04:50 <kparal> there is a bug in fedocal, it spans two days sometimes, in google calendar 16:04:54 <xmrbrz> Guys, I had a problem with gnome-boxes in TC7 workstation live basically the storage pool "gnome-boxes" was not created. 16:04:55 <kparal> we don't know the cause 16:04:56 <xmrbrz> https://www.dropbox.com/s/6ke4i9sfyrm0oab/gnome-boxes.png?dl=0 16:04:57 <xmrbrz> https://www.dropbox.com/s/nq4zttcnef2vzxi/libvirtd.png?dl=0 16:04:57 <adamw> #info Cockpit test day is tomorrow - https://fedoraproject.org/wiki/Test_Day:2014-09-16_Cockpit 16:04:57 <roshi> thanks for sending the announcement kparal 16:05:06 <xmrbrz> Related?!: https://bugzilla.redhat.com/show_bug.cgi?id=842114 16:05:07 <xmrbrz> [xmrbrz@localhost ~]$ virsh pool-list 16:05:09 <xmrbrz> error: failed to connect to the hypervisor 16:05:10 <sgallagh> jreznik: Sorry, just had a call from my kids' day-care and need to go bring my daughter to the doctor. 16:05:11 <xmrbrz> error: no valid connection 16:05:12 <xmrbrz> error: Failed to connect socket to '/run/user/1000/libvirt/libvirt-sock': No such file or directory 16:05:14 <adamw> xmb: please stop spamming. 16:05:14 <xmrbrz> Anyone else had this problem? (I did not test yet again) 16:05:15 <sgallagh> I'll be back later. 16:05:53 <jreznik> sgallagh: np, I have to leave too, just send me a note on email to understand what's the proposal is about and we can discuss it later 16:05:55 <adamw> xmrbrz: best to ask in #fedora-qa or #fedora, but yeah, that looks like the nested virt 192.168.122 subnet problem. 16:06:32 <adamw> so, if folks have five minutes to drop blog posts / social media / whatever about cockpit test day that'd be good, i'll do some today 16:06:42 <roshi> for sure 16:06:58 <kparal> xmrbrz: https://bugzilla.redhat.com/show_bug.cgi?id=811967 16:07:10 <xmrbrz> Ok then, sorry by spamm 16:08:14 <adamw> alrighty 16:08:17 * adamw sets quantum fuse 16:10:26 <adamw> thanks for coming, folks! we'll try and get TC8/RC1 done soon, then let's crank on testing it 16:10:28 <adamw> #endmeeting