16:01:13 #startmeeting f19final-blocker-review-7 16:01:13 Meeting started Wed Jun 19 16:01:13 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:13 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:13 #meetingname f19final-blocker-review-7 16:01:13 The meeting name has been set to 'f19final-blocker-review-7' 16:01:13 #topic Roll Call 16:01:22 #chair adamw kparal 16:01:22 Current chairs: adamw kparal tflink 16:01:44 ahoyhoy 16:01:59 * kparal arrives 16:02:05 * Viking-Ice fetches coffee 16:02:09 * ignatenkobrain here. 16:02:19 * nirik is lurking around 16:03:13 * handsome_pirate waves 16:03:40 lots o' people today. good 16:03:48 #topic Introduction 16:03:54 Why are we here? 16:03:54 #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 freeze exception bugs. 16:04:07 #info We'll be following the process outlined at: 16:04:07 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:04:15 #info The bugs up for review today are available at: 16:04:15 #link http://qa.fedoraproject.org/blockerbugs/current 16:04:23 #info The criteria for release blocking bugs can be found at: 16:04:23 #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria 16:04:26 #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria 16:04:29 #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria 16:04:57 #info Up for review today, we have: 16:05:05 #info 8 Proposed Blockers 16:05:06 #info 10 Accepted Blockers 16:05:06 #info 19 Proposed Freeze Exceptions 16:05:06 #info 18 Accepted Freeze Exceptions 16:05:10 * jreznik is here, from meeting to meeting, another meeting, wants back his old job to feel he's doing something real :D 16:05:25 Any volunteers for secretary duty? 16:05:59 sure 16:06:14 jreznik: but how can anything get done without meetings? 16:06:17 adamw: thanks 16:06:42 if there are no objections, we'll get started with the proposed blockers 16:07:35 #topic (975537) BootLoaderError: failed to remove old efi boot entry 16:07:38 #link https://bugzilla.redhat.com/show_bug.cgi?id=975537 16:07:40 #info Proposed Blocker, anaconda, ASSIGNED 16:07:57 /me listening 16:08:20 +1 16:08:35 we didn't reproduce this on Mac Mini 16:08:53 our efibootmgr output is a bit different though 16:09:05 also didn't reproduce on ThinkPad X230 16:09:14 looks like it might be hw specific. 16:09:38 the main question here is how widespread it is - seems like adamw was able to do the same on asus, kparal now reports it's not reproducible on mac mini... so it's definitely somehow hw specific - for one machine or more? that's the question 16:09:56 jreznik: adamw did not hit it. ;) 16:10:02 "And it's reproducible on three totally different Mac models. I don't have non-Apple UEFI to test, so I wonder if this is a regression that might affect non-Macs." 16:10:05 which is odd since chris says that he can reproduce the issue on 3 different macs 16:10:06 comment 17 16:10:15 jreznik: i said I *couldn't* reproduce it, not I could. 16:10:20 nirik: sorry - just my brain is in malfunction state - I meant, he couldn't 16:10:34 and believe me, i usually have no trouble hitting UEFI bugs. 16:10:36 so, as a workaround you can clear the pram? 16:10:45 the workaround is basically 'try again' 16:10:45 Looks like 16:10:48 chris says it works every second try 16:10:53 ha. nice. 16:11:14 so nvram clearing doesn't actually help. it's a bit unclear why it works on every second attempt 16:11:27 well, he was not clear whether he resets nvram after each attempt 16:11:33 this is one of those... how many people are affected that we have no idea on. ;( 16:11:35 we didn't reset the nvram at all, and everything worked 16:11:36 but that's what everyone usually do - tries it for the second time :) 16:11:54 my current inclination would be -1/+1 or punt 16:12:04 -1/+1 is my feeling as well. 16:12:05 but it's getting a bit late for punting 16:12:07 -1.+1 too. 16:12:19 if we can't fix it, we could commonbugs it. 16:12:30 -1/+1 here 16:12:32 yeah, at the moment, it seems a bit too HW specific to block over 16:12:35 * adamw pokes mjg59 16:12:38 we need developer feedback on this one if we are to accept it as a blocker. they need to know what's wrong, otherwise blocking won't help 16:12:39 -1/+1 and in case of more reports, we can rethink it 16:13:29 -1/+1 from me 16:13:42 proposed #agreed 975537 - RejectedBlocker AcceptedFreezeException - With the currently available information, this seems too HW specific to block release over but a tested fix would be considered after freeze. If more information or reports of hitting this show up, please repropose. 16:13:50 ack 16:13:58 ack 16:13:59 ack 16:14:02 ack 16:14:05 #agreed 975537 - RejectedBlocker AcceptedFreezeException - With the currently available information, this seems too HW specific to block release over but a tested fix would be considered after freeze. If more information or reports of hitting this show up, please repropose. 16:14:10 #topic (975159) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 0: ordinal not in range(128) 16:14:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=975159 16:14:15 #info Proposed Blocker, anaconda, MODIFIED 16:14:51 clear +1 blocker here 16:15:00 +1 16:15:02 +1 blocker 16:15:15 which one is this? we have a couple 16:15:22 oh, yeah, this is the worse one, +1 16:15:27 +1 yeah 16:15:41 +q 16:15:45 +1 16:15:47 +1 16:16:33 +werty 16:16:36 if you vote against this you have not tasted Czech beer 16:16:50 adamw: ah. sorry =) 16:17:06 right, gotta keep the czechs sweet 16:17:07 it's not just about Czech language :) 16:17:21 proposed #agreed 975159 - AcceptedBlocker - Violates the following F19 final release criterion for enough regions to justify blocking release: "The installer must be able to complete an installation using all supported interfaces" 16:17:25 ack 16:17:25 ack 16:17:27 ack 16:17:28 ack 16:17:30 ack 16:17:44 #agreed 975159 - AcceptedBlocker - Violates the following F19 final release criterion for enough regions to justify blocking release: "The installer must be able to complete an installation using all supported interfaces" 16:17:48 #topic (975692) Instalator hangs when it need to remove lvm with snapshot. 16:17:48 * handsome_pirate admits to not having tasted Czech beer, but has heard that it isn't so good 16:17:51 #link https://bugzilla.redhat.com/show_bug.cgi?id=975692 16:17:54 #info Proposed Blocker, anaconda, NEW 16:18:30 * handsome_pirate is leaning +1 blocker 16:18:44 are lvm snapshots common enough to block release over? 16:18:53 lvm still handles some snapshot cases poorly. ;( 16:19:17 anaconda dev input would be welcome here 16:19:20 +1 16:19:38 +1 from me. 16:19:47 how easy can they fix this, is this a trivial change? because changing lvm completely could break to many stuff 16:19:59 Good point, that 16:20:34 kparal: I think that easy, but I can be mistaken 16:21:16 the workaround would be to remove it manually before installing, i guess 16:21:19 definitely +1 fe 16:21:27 not sure about blocker 16:21:33 yep, I'm with adamw here 16:21:50 I suspect that people using lvm snapshots would be quite capable of working around this 16:22:01 and it seems like a bit of a corner case to block over 16:22:15 tflink: if they realize it's caused by the snapshot 16:22:17 yeah, I am leaning toward -1/+1 here... 16:22:24 that the installer cannot handle deleting a snapshot? 16:22:26 kparal: good point 16:22:38 and how much people even uses snapshots? it's really pretty corner case but would be great to have it working -1/+1 and document it in common bugs 16:22:54 also, duplication might be nice... was the snapshot full? lvm handles that very poorly. 16:23:04 Punt? 16:23:07 jreznik: I use them quite a bit but agree that it's rather obscure 16:23:27 I dont see the purpose of punting this one 16:23:47 the installer should be able to deal with snapshot at install time 16:24:11 however we should not be catching these problem so late in the cycle 16:24:16 what would we be punting for? 16:24:24 i guess the question of how hard it is to fix 16:24:38 my vote is a +1 fe as long as the fix isn't too invasive, of course 16:24:43 worst case scenario anaconda needs to be rewritten ;) 16:24:51 and how risky it is to fix 16:24:52 what could possibly go wrong ;)_ 16:24:59 that's just couple of months of blockages hehe 16:25:18 it sounds like we're pretty much -1/+1, though 16:25:21 it's just lvm, we can get rid of it again :) 16:25:22 ? 16:25:36 * kparal is torn 16:25:46 * adamw is -0.1/+1 16:25:51 :P 16:26:00 I'm still +1 here 16:26:15 it's not like the users get big fat warning that the cause is lvm snapshot 16:26:21 when this happens 16:26:37 the bug could really do with some logs 16:26:55 it could be nice to have the big fat warning as part of the media, release notes shown when running the installer 16:27:27 huh? 16:27:30 I see +0.9/-1 so far 16:27:45 has anyone not voted? 16:27:46 so do we want more info from reporter? I'm still more -1 blocker but ok to talk to lvm/anaconda guys about it 16:27:55 not today. But I'd briefly add that this is a blivet thing, and it needs logs. 16:28:06 I'm sorry. I have to go. +1 from me here. 16:28:18 I see +1.9/-1 so far 16:28:39 * handsome_pirate is -1/+1 now 16:28:55 If it is such a corner case ... 16:29:07 I'm for punting until we have logs and some dev can have a look at it. +1 FE right now 16:29:08 I'm -1/+1, too obscure to block over even if it isn't obvious 16:29:26 dlehman: please tell us that 975692 is extremely easy to fix 16:29:37 the main problem is that the user has no way of knowing that snapshot are causing this, if they did I would be like -1/+1 instead of +1 16:29:45 this wouldn't pass the last-blocker-at-go-nogo test 16:29:48 Viking-Ice: we don't even know that for sure, the report is pretty crappy 16:30:01 * tflink will try reproducing after the meeting 16:30:17 Viking-Ice: i'd give it about a 50% chance of being one of those reports where we ask for more details and the reporter's like 'oh, actually, if you wait 2 minutes it succeeds / fails with an actual error' 16:30:46 dlehman: do you have any idea on this one at this point, or just waiting for logs? if we assumed the issue was in fact precisely as described, would you think it should be a blocker? 16:30:47 there is certainly no code to enforce the ordering or removal for lvm snapshots versus origins 16:30:48 so p/+1 for now? 16:30:54 tflink: it's probably the best idea for now - to try to reproduce it 16:31:13 dlehman: would it be hard/dangerous to add that if it turns out to be what's needed? 16:32:03 * kparal is reproducing, give me a second 16:32:08 yes. snapshots are so seldom-used that the code around them is not in great shape. 16:32:09 second given 16:32:24 hmm 16:32:29 and we are -1/-1 16:32:35 so we're pretty confident that they're seldom used 16:32:47 seldom-used meaning "seldom relevant to bug reports" 16:32:52 ah. 16:32:58 but the code is still in bad shape 16:33:03 absolutely 16:33:20 LVMError: lvremove failed for root: running lvm lvremove --config devices { filter=["r|/loop5$|","r|/loop6$|","r|/loop7$|"] } fedora/root failed 16:33:23 in my case, it crashed 16:33:37 not hung 16:33:51 what's the error message? (program.log) 16:34:19 hmm, there might be an easy fix after all 16:34:35 not easy enough for where we are schedule-wise 16:34:45 okay 16:35:16 given that this is at least a corner case, i'm -1 if the maintainers aren't happy about putting in the fix at this point in the cycle 16:35:19 anyone still +1 or punt? 16:35:20 * kparal creating bug 975955 16:35:28 if this was a 'hits everyone' kinda bug i'd be 'just fix it, damnit!' but this is a different kind 16:35:35 dlehman: attaching info to bug 975955 16:35:55 and poking that broken code probably just breaks it some more 16:36:03 so for now i'm -1/-1, we can re-propose and revote if the data change 16:36:11 agreed 16:37:03 workaround: remove snapshots before install if you plan to remove their origins 16:37:22 file under: tough shit 16:37:22 -1/-1 based on above 16:37:39 proposed #agreed 975692 - RejectedBlocker RejectedFreezeException - This is a bit too much of a corner case to take as a release blocker and would poke sensitive code too close to release to take as a freeze exception. Thus, rejected as both blocker and freeze exception for F19 final. Please re-propose if the situation changes significantly. 16:37:48 ack 16:37:58 ack 16:38:01 thanks dlehman 16:38:05 ack 16:38:29 #agreed 975692 - RejectedBlocker RejectedFreezeException - This is a bit too much of a corner case to take as a release blocker and would poke sensitive code too close to release to take as a freeze exception. Thus, rejected as both blocker and freeze exception for F19 final. Please re-propose if the situation changes significantly. 16:39:09 topic (974711) Drop HAL and beefy install 'ad banners' for F19 final(?) 16:39:12 #link https://bugzilla.redhat.com/show_bug.cgi?id=974711 16:39:14 #undo 16:39:14 Removing item from minutes: 16:39:16 #undo 16:39:16 Removing item from minutes: 16:39:18 #info Proposed Blocker, fedora-logos, NEW 16:39:22 #topic (974711) Drop HAL and beefy install 'ad banners' for F19 final(?) 16:39:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=974711 16:39:28 #info Proposed Blocker, fedora-logos, NEW 16:39:53 who's bright idea was those add banner and who's going to translate all of them? 16:40:03 I'm not completely crear what's going on here 16:40:09 clear 16:40:28 I sincerely doubt that we have enough time to re-do and translate all the banners for final 16:40:41 tflink: it's not about translation 16:40:44 first and foremost are we getting paid for those advertisements 16:40:51 no, none of them are actually ads. 16:40:53 Viking-Ice: they aren't actually ads 16:40:53 they're just fedora stuff. 16:41:05 see https://fedorahosted.org/design-team/ticket/275 16:41:10 the basic point of the bug is that at least the HAL one should not be displayed, it's a jokey placeholder 16:41:18 cant we implement packman or tetris instead 16:41:23 adamw is not happy with the quality of banner, at least HAL should be removed, I agree so +1 FE 16:41:26 i don't care if the fix is just to take it out of the rotation, or put in some new ones that are all lined up, or just drop the banners entirely 16:41:29 Viking-Ice: what a great idea 16:41:32 Viking-Ice: ha, I like the idea 16:41:42 didn't some distro do that already? 16:41:46 i wanna say gentoo or arch? 16:41:56 adamw: for new ones, design guys would be ok to create such new ones but they need input from marketing... 16:41:58 ok ok angry bird no one has done angry birds 16:41:59 I didn't think they had graphical installers 16:42:06 well, some distro. anyhoo. 16:42:18 these ads are useless and distracting 16:42:31 my assumption when filing the bug was that there was an orderly Plan for this all along and when i filed it someone would just be like 'oh yeah, we have to take out those sucky placeholder banners and put in the REAL ones' 16:42:31 from staring at the installation bar 16:42:34 Viking-Ice: it's a part of the initial design... 16:42:37 but instead the response seems to be 'mass confusion' 16:43:12 dlehman: maybe you know what the plans are/were about the banners? 16:43:18 adamw: I'm not sure there's mass confusion - design guys understand it in the way "provide new ones" but they need to know "which ones" -> marketing 16:43:21 how are those banner turning out on varios sized screens? 16:43:30 kparal: no idea, sorry 16:43:40 i think all anaconda got told was 'display whatever's in (some directory) during install, we'll take care of populating it' 16:43:53 adamw: yep 16:44:17 * tflink is kicking himself for not raising more concern earlier - was told "of course they know what they're doing" and left it at that :( 16:44:22 jreznik: well, i mean, i was kind of assuming someone would have had this figured out like *two months ago*, not just be getting around to it now 16:44:27 tflink: right. 16:44:35 all of us assumed the same :) 16:44:38 what benefit are those banners supposed to bring us if we arent getting paid that? 16:44:51 for that 16:44:53 Viking-Ice: provide info to the user rather than just sit there staring at a progress bar 16:44:59 Viking-Ice: flickering stuff! 16:45:05 Viking-Ice: project advertising? new features, suggestions for new users etc. 16:45:06 seizuring stuff 16:45:08 chrome 16:45:14 adamw: yeah, definitely... I wasn't aware it's going to be implemented now and ticket to Design/Marketing should come much more earlier 16:45:16 i mean, most of the banners are actually saying something useful - 'you can find info at ask.fp.o', etc 16:45:29 like you remembered that link after install 16:45:33 just calling out LO and RB as apps and nothing else looks a bit odd, but it's valid info 16:45:41 anyway, we don't really need to bikeshed it here 16:45:46 for me the blocker issue is that HAL has to go 16:45:46 +1 FE to remove HAL and I'd say it would be enough for now 16:45:57 * handsome_pirate sees nothing wront with HAL or Beefy 16:45:59 i'd still want that to be blocker not FE, but otherwise agree with jreznik 16:46:01 I vote we remove this completely 16:46:02 +1 blocker until legal says HAL is OK 16:46:10 or it gets removed 16:46:17 Viking-Ice: that would be my preferred option, but i'd only want to *block* on getting rid of hal 16:46:20 At the least keep Beefy! 16:46:23 HAL might be legally OK, but it's not suitable there 16:46:48 +1 for blockage until removal and any picture with text on needs to be translated 16:46:51 true, but I'm not sure I can see blocking over HAL if legal said it was OK 16:46:57 I support adamw in blocking until HAL is away, or someone confirms it should really really be there 16:46:57 * jreznik is ok with blocking and he would really like to see more meaningful banners but it's more F20 dream 16:47:12 Viking-Ice: atm the banners are just not displayed unless the language is english, which 'solves' the translation problem 16:47:20 adamw, this is installer spam 16:47:22 Viking-Ice: as far as I understand it - it's displayed only in English 16:47:40 translation is the next step for future releases 16:47:41 maybe English and Icelandic, to annoy Viking-Ice :) 16:47:53 kparal: :D 16:47:58 anyway, seems like we're solidly +1 blocker for hal at least 16:48:30 kparal, annoying indeed unlike other country's we invent words our language does not already cover which means nobody know what fracking says there in the first 16:48:38 place 16:49:10 Viking-Ice: oh, france does that too, but french people don't actually *use* them 16:49:30 proposed #agreed 974711 - AcceptedBlocker - There are significant questions about some of the banners displayed during installation (legal, appropriate content for Fedora etc.). There are several possible solutions (removing specific banners, removing banners, legal review ...). 16:49:35 but back to topic death to all installer banners 16:49:43 ack 16:49:46 ack 16:49:57 nice and vague, but i guess ack 16:50:03 Viking-Ice: Ubuntu does it right. at least the last time I tried it, some years ago 16:50:12 adamw: I can rewrite it 16:50:16 i'd be happier with just 'kill hal', personally 16:50:17 it's really pretty vague 16:50:22 adamw: yep 16:50:28 the current text looks like a recipe for confusion and i'd probably rewrite it in the bug by fiat :P 16:50:43 we don't mind if they want to go further, but at a minimum, hal has to go 16:50:51 adamw: you can #propose 16:51:30 proposed #agreed 974711 - AcceptedBlocker - There are significant questions about some of the banners displayed during installation (legal, appropriate content for Fedora etc.). There are several possible solutions (removing specific banners, removing banners, legal review ...). At a minimum, the HAL (I can't let you do that, Dave) needs to be removed before the blocker classification is dropped or the bug is closed. 16:51:35 better? 16:52:03 ack 16:52:05 better 16:52:12 ack 16:52:15 ack 16:52:29 #agreed 974711 - AcceptedBlocker - There are significant questions about some of the banners displayed during installation (legal, appropriate content for Fedora etc.). There are several possible solutions (removing specific banners, removing banners, legal review ...). At a minimum, the HAL banner (I can't let you do that, Dave) needs to be removed before the blocker classification is dropped or the bug is closed. 16:52:40 #topic (975204) radeon card lost opengl 3.1 support 16:52:40 #link https://bugzilla.redhat.com/show_bug.cgi?id=975204 16:52:40 #info Proposed Blocker, mesa, ON_QA 16:53:57 from talking to ajax yesterday, this was a mistake that breaks opengl for both nvidia and amd cards 16:54:18 my understanding is that the change is a compile flag that wasn't set correctly 16:54:23 does it break OpenGL completely, or just lowers the supported version? 16:54:38 kparal: lowers 16:54:47 +1 FE for sure 16:54:51 so everything works, but it's not that nice? 16:55:00 no loss of functionality? 16:55:21 openarena still works, etc? 16:55:23 kparal: I understand it this way, you can loose some functionality in the newer open gl but nothing blocking 16:55:28 note this fix is in TC5 already 16:55:36 in that case I don't see the need for blocker 16:55:41 +1 FE is enough 16:55:43 i'm +1 FE for sure, blocker is a harder sell, from the bug report it only affects steam or something 16:55:44 yep 16:55:46 kparal: openare works even with my 1.x opengl :) 16:56:01 -1/+1, move on 16:56:22 -1/+1 16:57:11 proposed #agreed 975204 - RejectedBlocker AcceptedFreezeException - This doesn't cleanly violate any F19 release criteria and does not qualify for release blocking status for F19. However, the fix is low-risk and the bug is a regression in expected functionality and a tested fix would be considered past freeze. 16:57:17 ack 16:58:22 ack 16:58:41 ack 16:58:44 #agreed 975204 - RejectedBlocker AcceptedFreezeException - This doesn't cleanly violate any F19 release criteria and does not qualify for release blocking status for F19. However, the fix is low-risk and the bug is a regression in expected functionality and a tested fix would be considered past freeze. 16:58:49 #topic (974691) Since cleaning up from #974132, nothing gets written to /var/log/messages 16:58:52 #link https://bugzilla.redhat.com/show_bug.cgi?id=974691 16:58:54 #info Proposed Blocker, rsyslog, NEW 16:59:23 on second thought, should probably skip this one for today 16:59:29 ball is at adamw it seems 16:59:36 yeah, my bad, sorry 16:59:41 I'm -1/-1 16:59:42 this keeps getting pushed down by other testing 16:59:46 this can be fixed via update 16:59:48 but if no-one else is seeing this we could reject it 17:00:09 I've not looked for it, to be honest 17:00:12 this is a fallout after you guys fiddle with rsyslog right 17:00:14 has anyone else seen this? or does everyone else seem to be getting all stuff from journal in their /var/log/messages just fine? 17:00:36 Viking-Ice: i'm not sure, that's the thing - not sure whether it's just fallout from fixing that bug somehow, or if it might affect fresh installs 17:00:39 (and lives) 17:00:50 tflink: easy enough to check, it'd take like 5 secs 17:00:52 the journal is populated if that is the case 17:01:04 tflink: just compare journalctl -a and /var/log/messages , and look for the message i mentioned in journalctl 17:01:06 it's not like we are leaving users without logs 17:01:14 Viking-Ice: true 17:01:59 my argument is that the 'relevant standards' thing kinda implies that we must have and populate /var/log/messages 17:03:06 anyone with f19 want to check if this is affecting you real fast? 17:04:50 I'm seeing the "missed messages" line in journalctl 17:04:53 * kparal doesn't have it around 17:05:06 tflink: did you have to clean up the explosions on your system? 17:05:16 tflink: and what rsyslog do you have? 17:05:17 adamw: this is a fresh install I did yesterday 17:05:23 systemd-journal[307]: Forwarding to syslog missed 65 messages. 17:05:30 hum 17:05:35 rpm -q rsyslog? 17:05:46 rsyslog-7.2.6-1.fc19.x86_64 17:05:58 the odd thing is that there is stuff in messages 17:06:06 and it looks at least somewhat up to date 17:06:16 tflink: how many of those 'forward missed' messages do you have? just one? 17:06:34 hi 17:06:38 two, just one per day 17:06:46 but I just turned the machine on 17:06:47 I can see the missed 68 messages in journalctl -a 17:06:52 hi masta 17:06:59 looks like we need to look into this a bit more 17:07:01 * masta was lurking 17:07:11 i had way more than that when i reported the bug 17:07:19 Jun 17 19:22:09 adam.localdomain systemd-journal[3084]: Forwarding to syslog missed 1 messages. 17:07:19 Jun 17 19:23:00 adam.localdomain systemd-journal[3084]: Forwarding to syslog missed 5 messages. 17:07:19 Jun 17 19:23:30 adam.localdomain systemd-journal[3084]: Forwarding to syslog missed 45 messages. 17:07:19 Jun 17 19:27:58 adam.localdomain systemd-journal[3084]: Forwarding to syslog missed 15 messages. 17:07:23 etc etc etc etc - like, every few minutes 17:07:31 but I don't have any since jun 17, like it somehow cleared up 17:07:48 maybe the journal file got rotated and that cleared it up somehow 17:08:04 in a fresh install I have just one 'missed' line, 36 messages missed, early in boot 17:08:19 so maybe there's a general problem that it misses forwarding some messages in early boot, but that's probably not blocker material. 17:08:29 perhaps it's just messages that are so early the filesystem isn't mounted yet. 17:08:33 yeah, this is starting to sound like not a blocker 17:08:49 i guess i'm -1 or punt at this point 17:08:56 other votes? 17:09:26 -1/-1 and this probably is a rsyslog bug 17:09:30 ( not journal ) 17:09:52 -1/-1, doesn't seem blocker worthy off hand. 17:10:13 i can always repropose if this turns out to be worse. 17:10:54 * nirik nods 17:10:55 sure, but please not a day before go/no-go :) -1/-1 and let's try to talk to devs, I'll do it tmrw to see what's really going on 17:11:20 proposed #agreed 974691 - RejectedBlocker - This appears to have become less severe than we initially thought and it no longer violates any of the F19 release criteria. Thus, rejected as a release blocking bug for F19 final. 17:11:38 ack 17:11:46 ack 17:11:49 ack 17:12:19 #agreed 974691 - RejectedBlocker - This appears to have become less severe than we initially thought and it no longer violates any of the F19 release criteria. Thus, rejected as a release blocking bug for F19 final. 17:12:24 #topic (975521) unable to change settings using dconf 17:12:24 #link https://bugzilla.redhat.com/show_bug.cgi?id=975521 17:12:25 #info Proposed Blocker, selinux-policy, MODIFIED 17:12:59 -1/-1 17:13:05 can be fixed via update 17:13:21 we're not totally sure this is nailed down yet 17:13:25 actually this can be quite serious 17:13:27 i'd like to keep the option on it for a bit longer 17:13:36 broken dconf is serious 17:13:43 kparal, broken dconf happens up upgrades 17:13:45 i think dan408 may have hijacked/derailed it a bit 17:14:10 Matus Marhefka made a clean TC5 DVD install and noticed dconf broken 17:14:11 matus reports that he install then starts manually fiddling with dconf 17:14:15 Viking-Ice: multiple people have reported their dconf database just getting 'mysteriously' corrupted, sometimes after a hard system freeze, sometimes apparently not. it's all a bit mysterious, but it seems worth investigating at least 17:14:26 I'm using tc5 mate and dconf seems to work here 17:14:36 the upstream reports also indicates dconf problem 17:14:41 Viking-Ice: he didn't say he was 'fiddling with dconf' 17:14:50 Viking-Ice: he just tried to do some perfectly normal operations that happen to be backed by dconf 17:15:05 "Try to remove icons from GNOME Shell favourites launcher or change background or any other changes requiring dconf." 17:15:12 Matus is a bit succinct, but I talked to him quite a bit and it was just a clean install 17:15:17 "Try to remove icons from GNOME Shell favourites launcher or 17:15:17 change background or any other changes requiring dconf." sounds fixable with 0 day to me 17:15:33 Viking-Ice: icons are just a symptom of broken dconf 17:15:39 no gnome settings would be saved 17:15:39 I'm not sure we have enough info to make a call on that ATM 17:15:42 it's not as easily reproducible as that for me, but i'd quite like to figure out what's going on with the dconf borkage before rejecting 17:16:17 i'm probably punt at this point 17:16:26 yeah 17:16:30 yeah sure let's punt 17:17:39 if people can keep an eye out for their dconf 'mysteriously' getting corrupted and yell for a GNOME dev if it happens that'd probably help 17:17:43 and keep an eye on the upstream bug 17:18:14 proposed #agreed 975521 - It's not clear on what exactly is causing the bug as reported and we want to be more sure that there aren't larger dbus issues here before making a decision on blocker status. Will revisit when more information is available 17:19:10 patch 17:19:11 adamw: reassign to dconf together with providing this info^^? 17:19:11 ack 17:19:13 s/dbus/dconf/ 17:19:28 kparal: seems reasonable 17:20:48 hum, OPs journalctl output does have a "Jun 18 12:23:46 localhost.localdomain systemd-tmpfiles[2038]: stat(/run/user/1000/gvfs) failed: Permission denied" line 17:20:52 oh, whoops 17:21:12 proposed #agreed 975521 - It's not clear on what exactly is causing the bug as reported and we want to be more sure that there aren't larger dconf issues here before making a decision on blocker status. Will revisit when more information is available 17:21:19 but that's *after* the dconf errors show up 17:21:49 ack 17:22:23 ack 17:22:58 ack 17:23:01 #agreed 975521 - It's not clear on what exactly is causing the bug as reported and we want to be more sure that there aren't larger dconf issues here before making a decision on blocker status. Will revisit when more information is available 17:23:06 #topic (679486) Liveinst doesn't start if hostname changes 17:23:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=679486 17:23:07 #info Proposed Blocker, xorg-x11-xauth, ASSIGNED 17:23:37 I guess I'll get "shoot the messenger" feedback for this one 17:24:19 I was playing a bit with my network cables and found out that anaconda fails to start 17:25:50 I guess bcl's comment means the problem is real, not just in my machine 17:26:05 (read from comment 72 onwards) 17:27:11 * jreznik pinged t8m today, he does not think it's pam issue but it's worth investigation and how old this bug is??? 17:27:51 jreznik: it depends whether we want to solve it even for dhcp hostnames, or just for network disconnect. it might be two separate issues 17:28:04 or maybe it's the same root cause, I don't know 17:28:43 as mentioned in the bug i'm probably +1 at this point 17:28:54 i seem to see more and more people hitting this bug lately, and it's a pretty sucky bug 17:29:20 my hack to fix it is really simple, but I don't know if it might cause troubles for other distributions using anaconda 17:29:33 interestingly enough, I haven't seen it. then again, almost all of my live installs are in VMs 17:29:53 tflink: have you tried to boot the VM, disable the wired connection and run anaconda? 17:29:55 kparal: bcl said he tried the 'run xhost through sudo' fix and it didn't work 17:30:01 it's very simple and fast to check 17:30:20 kparal: nope, I was more referring to the dhcp hostname case 17:30:37 adamw: bcl said he tried to run xhost under root with :0. but not with sudo 17:30:47 * tflink makes heavy use of dhcp hostnames on his network 17:30:52 if I read it correctly 17:31:13 tflink: well, our office is still affected :) 17:31:42 tflink: either you have fast network or slow machines 17:31:51 kparal: sure, I'm mostly surprised that I haven't hit this yet - not saying that I don't believe it exists 17:32:02 * adamw pastes the irc log 17:33:48 kparal: or I just haven't done live installs on bare metal in a while :) 17:34:10 adamw: the log doesn't seem to have arrived 17:34:19 it's there - c#78 17:34:27 kparal: https://bugzilla.redhat.com/show_bug.cgi?id=679486#c78 17:34:27 ah 17:34:33 sorry, meant into the bug :) 17:35:20 interesting, I'm quite sure it worked well for me. I'll try again 17:36:48 re-tested, works great for me 17:37:15 we're still at the question of whether or not this is enough to block release over 17:37:27 +1 here 17:38:07 +2 from bug comments (adamw and jsmith) 17:39:14 still evaluating 17:39:18 I'm more +1 than -1 but I'm not so sure this passes the last-blocker-at-gonogo test 17:39:39 i'd kick pretty strongly, given the number of people i've seen run into it just casuaslly 17:39:45 there was another one in #fedora-qa just yesterday 17:40:26 we have released with it before so going by adamw standards that means it's not a blocker now 17:40:44 actually I can verify that easily 17:41:30 the workaround seems pretty obvios disconnect and install 17:41:52 the workaround is to reboot once you disconnected, or use sudo 17:42:00 Viking-Ice: at the time we thought the impact was strictly limited to 'dhcp hostnames' 17:42:05 Viking-Ice: that doesn't seem to be the case any more 17:42:06 it's definitely happening for a long time for quite a few people - we've already fudged it several times, there are simple workarounds but would be great to solve it, so I'm more +1 17:42:16 Viking-Ice: that's why I changed my votye 17:42:20 ok, in F18, anaconda does crash instead of looping 17:42:34 if I boot and disconnect wired 17:43:25 but we didn't know that at that time 17:43:52 no one was insane enough to disconnect network, until me :) 17:43:59 yeah but dealing with this bug this late things might go horrible wrong 17:44:19 if the cure turns out to be worse than the disease we could re-consider 17:44:32 actually it seems that the fix would be very easy to test 17:44:49 proposed #agreed 679486 - AcceptedBlocker - Violates the following F19 alpha release criteria for several reasonably common liveinstall use cases which we were not aware of before: "The installer must run when launched normally from the release-blocking images." 17:44:55 ack 17:45:00 ack 17:45:07 ack 17:45:16 #agreed 679486 - AcceptedBlocker - Violates the following F19 alpha release criteria for several reasonably common liveinstall use cases which we were not aware of before: "The installer must run when launched normally from the release-blocking images." 17:45:30 ok, that's all of the proposed blockers on my list for today 17:45:34 * kparal brb in 5 17:46:23 we have a little over an hour left 17:46:42 do we want to go over all of the proposed FEs? 17:46:53 I was planning to filter by bug status 17:47:27 filter by bug status and start with those 17:47:28 yeah let's go over the proposed FE since they are piling up 17:47:30 then do the rest if we have time 17:47:57 #topic (972328) ibus shouldn't require ibus-setup 17:47:58 #link https://bugzilla.redhat.com/show_bug.cgi?id=972328 17:47:58 #info Proposed Freeze Exceptions, ibus, ON_QA 17:49:51 +1 - helps to get stuff off the desktop spin to make it properly sized 17:49:58 +1 17:50:08 +1 17:50:09 +1 17:50:40 proposed #agreed 972328 - This is a low-risk action that removes un-needed pkgs from the desktop spin to help get it down to the target size. A tested fix would be considered past freeze. 17:50:45 ack 17:50:46 ack 17:50:54 ack 17:50:56 * Viking-Ice brb 10 mins 17:50:59 #agreed 972328 - This is a low-risk action that removes un-needed pkgs from the desktop spin to help get it down to the target size. A tested fix would be considered past freeze. 17:51:03 #topic (965797) Warn on skip of user creation 17:51:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=965797 17:51:08 #info Proposed Freeze Exceptions, initial-setup, POST 17:53:13 +1, firstboot used to do this and i-s really should 17:53:37 i got caught out by this in a KDE install just yesterday, in fact - merrily closed i-s having forgotten i hadn't created a user during install 17:53:39 what is the fix, exactly? so that i-s warns if there is not a user account? 17:54:42 * nirik is also not clear what the patches are. 17:54:44 it will warn you if you try to quit with no user accounts present 17:54:54 you can still do it, you just have to click through the warning 17:54:59 same behaviour as firstboot basically 17:55:14 ok 17:55:16 ok, +1 17:55:16 +1 17:55:18 https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-June/004516.html 17:55:19 sounds good 17:55:20 +1 17:55:21 is the patch 17:55:29 +1 17:56:33 proposed #agreed 965797 - AcceptedFreezeException - This decreases the odds that a user will finish install and post-install processes without a user account but allows corner cases to finish without creating a user account. A tested fix would be considered past freeze. 17:56:45 ack 17:56:45 ack 17:57:00 ack 17:57:01 ack 17:57:02 #agreed 965797 - AcceptedFreezeException - This decreases the odds that a user will finish install and post-install processes without a user account but allows corner cases to finish without creating a user account. A tested fix would be considered past freeze. 17:57:06 #topic (970719) initial-setup-text.service causes endless lvm messages to the console 17:57:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=970719 17:57:11 #info Proposed Freeze Exceptions, initial-setup, ON_QA 17:59:15 are there use cases for this outside of arm w/o graphics? 17:59:50 secondary arch auto FE right 18:00:09 yep, there are and actually it's the only place where I-S is really needed 18:00:33 yeah, this is for arm deployments basically 18:00:51 the design for f19 is that we use i-s to let people set root password etc on pre-built arm images 18:00:59 yep 18:01:02 (for prior releases there was just a hardcoded root password, iirc, which sucked) 18:01:03 +1 here 18:01:07 + 18:01:11 so +1 in general to anything that fixes up i-s to work in that case 18:01:21 it's got to be good for something... ;) 18:01:35 (+ has to be enough, I have to save 1 key) 18:01:48 but you used a bunch more telling us that. ;) 18:01:55 +1 18:02:23 +1 18:02:36 proposed #agreed 970719 - AcceptedFreezeException - This allows ARM to not use static root passwords in the case when no graphical console is used. A tested fix would be considered after freeze. 18:02:42 +1 i think its fixed in TC5 18:02:51 jreznik: and I can't use AcceptedFE instead of AcceptedFreezeException? 18:03:28 ack 18:03:32 ack 18:03:35 ack 18:03:35 ack 18:03:39 ack 18:04:02 tflink: i wouldn't mind that use in the meeting at all, it's in context 18:04:07 tflink: i just don't want to use it on bugs 18:05:02 #agreed 970719 - AcceptedFreezeException - This allows ARM to not use static root passwords in the case when no graphical console is used. A tested fix would be considered after freeze. 18:05:24 #topic (975214) Implement package installation policy agreed in FESCo #1115 18:05:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=975214 18:05:30 #info Proposed Freeze Exceptions, PackageKit, VERIFIED 18:06:00 why is this only changing _now_? 18:06:20 because fesco sucks at tracking their decisions? 18:07:27 +1 FE 18:07:33 is this not a blocker? 18:07:33 adamw: indeed they do 18:07:40 +1 to FE 18:07:54 Viking-Ice: doesn't violate any criteria 18:08:14 Viking-Ice: really fesco ought to track their own 'blockers', but that seems to be a lost cause 18:08:18 dgilmore, fesco decitions " It needs to be implemented for final release." 18:08:27 Viking-Ice: what i've been talking about with them is a proposal whereby we add a criterion for FESCo decisions 18:08:29 yeah, just like that 18:08:41 but that's probably F20 stuff at this point 18:08:47 ok +1 anyway 18:08:48 Viking-Ice: we dont have release criteria that says all fesco design decisions must beimplemented 18:08:49 yeah 18:08:58 as the change for this is in already we can fortunately just take it as an FE 18:09:03 and do the criteria/process change for f20 18:09:19 +1 FE 18:09:24 I'm confused - is the process change to allow some packages to be installed by a non-admin user or to prevent it? 18:09:34 tflink: the change is a tightening of the policy 18:09:44 dgilmore, I do believe fesco is supposed to superseed us. you know like giving fedup official upgrade status and what not 18:09:59 before the change, pretty much anyone can install any signed package from a trusted repo without any authentication, inc. non-admin users 18:10:31 Viking-Ice: sure, it's just about how exactly we track 'fesco blockers' - should fesco do it themselves or do we just want to write it into the blocker process 18:11:13 we should not add it to our existing process 18:11:26 they make the decition they take the fall 18:11:32 if shit hits the fan 18:12:56 anyhow, out of scope for this meeting 18:13:14 proposed #agreed 975214 - AcceptedFreezeException - This is required for implementation of a 4 week old FESCo decision and tighter restrictions on who can install packages on the system. A tested fix would be considered past freeze. 18:13:21 tflink: the change tightens the policy down so that, as i understand it anyway, non-admin users must auth as root to install packages, and admin users either have to auth as themselves or can still do it without authing 18:13:26 and approving fedup as the official upgrading while it was literally being written and not properly testes is dodgy at best 18:13:32 ack 18:13:34 ack 18:13:51 ack 18:13:58 #agreed 975214 - AcceptedFreezeException - This is required for implementation of a 4 week old FESCo decision and tighter restrictions on who can install packages on the system. A tested fix would be considered past freeze. 18:14:05 #topic (973019) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 0: ordinal not in range(128) 18:14:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=973019 18:14:11 #info Proposed Freeze Exceptions, python-blivet, POST 18:14:29 this is the other ascii bug, definitely +1 18:14:43 ascii bug? 18:14:53 oh, looking at the wrong bug again 18:14:55 damnation 18:15:23 this one looks like a real blocker to me 18:15:28 +1, seems easy to trigger. why not blocker? 18:16:07 it's not *super* easy to trigger 18:16:26 ? 18:16:37 what's your definition of super easy? 18:16:40 I guess this is the patch: https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-June/004692.html 18:17:14 I would say a blocker to ensure we pull in that patch 18:17:23 hum, am I thinking of another bug here? 18:17:23 I guess it applies to devices with non-ascii labels or something 18:17:51 i feel like there was one like this but it had more complex reproduction steps 18:18:13 anyhow, at very least +1 fe, could be a blocker depending on details 18:18:46 +1 FE, ask vpodzime if it is serious enough to warrant a blocker 18:18:55 it's going to be pushed in the meantime and everyone is happy 18:19:09 + fe 18:19:13 +1 again :( 18:19:18 obvious +1 18:19:34 proposed #agreed 973019 - AcceptedFreezeException - This is pretty easy to hit with non-ascii labels and a tested fix would be considered past freeze. 18:20:27 ack 18:20:48 ack 18:21:01 ack 18:21:12 ack 18:21:17 we can re-propose as a blocker if it needs to be 18:21:58 #agreed 973019 - AcceptedFreezeException - This is pretty easy to hit with non-ascii labels and a tested fix would be considered past freeze. 18:22:04 #topic (975643) SELinux is preventing /usr/sbin/mdadm from 'ioctl' accesses on the blk_file /dev/md126p1. 18:22:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=975643 18:22:10 #info Proposed Freeze Exceptions, selinux-policy, MODIFIED 18:22:20 I wonder if this is a dupe of an issue I hit yesterday 18:22:32 .bug 975495 18:22:36 tflink: Bug 975495 AVC Denials When Installing F19 Live Desktop to mdraid RAID1 - https://bugzilla.redhat.com/show_bug.cgi?id=975495 18:23:09 +1 FE either way from me 18:23:31 +1 FE also walks on a fine blocker line... 18:23:48 true, but it is more cosmetic than anything 18:23:52 the install completes without issue 18:24:43 yeah, since the AVC criterion is a cosmetic one i'd say the bar for it is quite highj 18:25:05 it really needs to be an AVC that tons of people are going to see - the intent of the criterion is for us not to look embarrassingly unprofessional 18:25:15 so i'm okay with FE not blocker 18:25:35 you do realize uses seeing false positives looks really bad 18:25:37 tflink: very likely the same thing, yeah 18:25:46 mean users 18:25:51 Viking-Ice: sure, that's why we have the criterion. but you only see this one for live installs to mdraid. 18:26:03 anyhow, there's a fix already, so we don't need to argue it too far 18:26:39 +1 FE 18:27:04 proposed #agreed 975673 - AcceptedFreezeException - While this isn't quite common enough to be a blocker, showing un-needed error messages to users is a bad practice. A tested fix would be considered past freeze. 18:27:11 ack 18:29:40 other thoughts? 18:29:54 ack 18:29:56 ack 18:30:01 ack 18:30:04 #agreed 975673 - AcceptedFreezeException - While this isn't quite common enough to be a blocker, showing un-needed error messages to users is a bad practice. A tested fix would be considered past freeze. 18:30:11 #topic (975344) SELinux is preventing spice-vdagentd from 'module_request' accesses on the system . 18:30:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=975344 18:30:17 #info Proposed Freeze Exceptions, selinux-policy, MODIFIED 18:30:36 kinda similar, i saw this in two non-blocking desktops 18:31:30 yeah 18:31:32 +1 FE 18:31:35 +1 18:32:34 proposed #agreed 975344 - AcceptedFreezeException - This has only been reported on secondary de livecds and thus isn't a blocker but is a freeze exception. A tested fix would be considered past freeze. 18:33:25 ack 18:33:27 ack 18:33:34 ack 18:33:45 #agreed 975344 - AcceptedFreezeException - This has only been reported on secondary de livecds and thus isn't a blocker but is a freeze exception. A tested fix would be considered past freeze. 18:33:51 #topic (975780) java-1.7.0-openjd security update should go to f19 final compose 18:33:54 #link https://bugzilla.redhat.com/show_bug.cgi?id=975780 18:33:57 #info Proposed Freeze Exceptions, distribution, ON_QA 18:35:22 so ... there is a security issue with some java dep of icedtea-web and an update to both is needed? 18:35:28 Jiri is a bit chaotic person, but he wants to say that openjdk CVE fix should be on the final media 18:35:45 shouldn't this be a blocker? 18:35:45 and icedtea-web won't work with the new openjdk without an update 18:35:49 dunno 18:35:56 oh, openjdk - I was just reading the title 18:36:04 "what is openjd?" 18:36:12 i think im +1 18:36:22 there are like 20 fixed CVEs or so 18:36:23 where is the CVE? 18:36:28 id rather fix a CVE if we can 18:36:36 are the, rather - this could qualify as a blocker 18:36:42 those bugs are private, so I said Jiri to create a public bug and propose it 18:37:42 why are CVEs private? oh well 18:37:54 I guess because of security concerns? 18:37:56 0 day update? 18:38:02 tflink: because these are CVEs? it's security word... 18:38:12 CVEs are a semi-public database 18:38:36 the US government indirectly pays for the db, IIRC 18:38:44 bugs filed against fedora should not be held private periot 18:38:46 but I difress 18:38:52 funded by NSA? :-) 18:38:59 Viking-Ice: there's a whole policy in place for security bugs 18:39:20 Viking-Ice: not as easy, but after embargo is lifted these could be made public 18:39:40 kparal: possible but it goes through a few layers of government fun first 18:39:40 jreznik, easy enough with our own bugzilla instance 18:39:57 so why not have this a 0 day update 18:40:02 openjdk guys would even like to see private builds, board approved it, it was never implemented 18:40:07 I don't see any reason to deny FE 18:40:08 is icedtea on the lives? 18:40:14 tflink: no, just DVD 18:40:17 no 18:40:17 The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)" 18:40:27 tflink: but openjdk is on Live 18:40:31 so the question is - what's the clasification? 18:40:53 if we want to get picky, there are no security bugs here 18:40:53 (there's update mentiened, /me is silent) 18:40:58 since there are dozens of CVEs fixed, I guess it's high. but we can ask for more info 18:41:01 none that we can see anyways 18:41:26 tflink: i'd take a comment from the security team that the update fixes 'important' or higher CVEs. 18:41:34 I could have asked for private bug links, right 18:41:44 * adamw doesn't remember how the whole security embargo process works exactly 18:41:52 adamw: I did say if we want to get picky 18:42:30 adamw: if they have built updates the CVE's have to be public and not under embargo 18:42:31 kparal: just asking for them 18:42:38 we have no way to hide things 18:42:40 jreznik: who/ 18:42:59 ha, there are 108 java CVEs from the last 3 months 18:43:08 kparal: a few moments ago jkejda came to me he's working now to get these CVEs done :D 18:43:19 if they have commited fixes for CVE's under embargo then that would be bad 18:43:24 as dgilmore said - if there's build, embargo is lifted 18:43:31 jreznik: they are not already fixed in the build? 18:44:01 kparal: are or not? I see ON_QA 18:44:09 tflink: yes, jvanek said the number of CVEs was "very ugly" 18:44:15 anywho +1 dont see any risk pulling this in and follow the newly introduced security criteria 18:44:22 kparal: so he's working on oracle one 18:44:40 yeah, anyway, +1 fe at least, this should probably be a blocker. 18:44:53 jreznik: I think we don't understand each other, nevermind :) the openjdk build should address a lot of them, according to my knowledge 18:45:05 kparal: yeah :D 18:45:14 +1 fe 18:45:49 proposed #agreed 975780 - AcceptedFreezeException - Java has plenty of security issues and while the CVEs fixed in this update aren't readily accessible, we assume that this is worth pulling into the DVD and lives. A tested fix would be considered after freeze. 18:45:59 since icedtea-web is not on Live, I don't see this as absolutely critical. but FE it is for sure 18:46:03 ack 18:46:45 well, the CVEs are in openjdk, no? 18:47:36 yes 18:47:49 but icedtea-web allows to run java from browser 18:47:57 if you don't have it, you need to download a java program and run it 18:48:11 so it's not that easily misused 18:48:39 my point was that the icedtea stuff wasn't the primary motivation for fe/blocker - just to make sure it still works after the security fixes 18:48:48 ackl 18:49:11 correct, the motivation is openjdk. icedtea-web update just ensures it works again with the new update 18:49:22 *new openjdk update 18:49:31 other ack/nak/patch? 18:49:42 right, what we're doing here is taking openjdk as an FE issue 18:49:59 and it happens that the update has to include icedtea-web as that has to be rebuilt for openjdk, but that's basically an irrelevant detail 18:50:02 ack 18:50:10 ack 18:50:32 #agreed 975780 - AcceptedFreezeException - Java has plenty of security issues and while the CVEs fixed in this update aren't readily accessible, we assume that this is worth pulling into the DVD and lives. A tested fix would be considered after freeze. 18:50:47 OK, that's all of the filtered proposed FEs 18:50:54 we have 10 minutes left 18:51:19 I'm wondering if it might be best to stop now and reconveine later 18:51:41 at some point, we might want to go through the accepted FEs to see if they're still appropriate to be taking as freeze goes on 18:52:15 let's stop for today, 8 minutes left... 18:52:38 just stop for today 18:52:46 at the rate people are responding, I agree :) 18:52:49 sorry gimme one sec 18:52:52 #topic Open Floor 18:52:56 there may be a couple i want to pull out of the proposed FE 18:53:01 just catching up with ecretaryization 18:53:27 do we want to just meet tomorrow, I'm not sure about leaving it all for monday 18:53:38 https://bugzilla.redhat.com/show_bug.cgi?id=974543 18:54:20 dances on the limit of blocker 18:54:27 * kparal won't be available tomorrow 18:54:33 https://bugzilla.redhat.com/show_bug.cgi?id=873207 18:54:37 https://bugzilla.redhat.com/show_bug.cgi?id=975649 18:54:40 are three i'd like to pull out 18:55:13 the g-i-s crash seems to happen 'sometimes' after GNOME install and first boot 18:55:23 seems cosmetic, but obviously be nice to get rid of it 18:55:29 we should definitely try and get UEFI dualboot working 18:55:45 and that last one basically blocks raid1 install from live images for me at least 18:55:45 * jreznik could help a bit tomorrow, earlier, better 18:56:09 adamw: the first one is not about g-i-s 18:56:35 kparal: just swapped 18:56:37 but we should definitely vote on 974543 18:56:46 oh, i meant to add https://bugzilla.redhat.com/show_bug.cgi?id=962092 . 18:56:48 it's proposed and patches are ready 18:57:09 +1 on 974543 18:57:20 +1 FE for 974543, seems like bcl wants this one 18:57:20 adamw: how are we looking for TC6/RC1? think we will want to do it today? 18:57:35 ah, the status got changed for some reason on 974543 18:57:39 dgilmore: possibly, i'll have to take a look through the lists once the app updates, and sync with bcl for 19.30.9 18:57:47 so ... keep goin? 18:57:52 #undo 18:57:52 Removing item from minutes: 18:57:57 at least vote on what we can in the next 3 mins 18:57:59 #topic (974543) Anaconda is always creating new efi system partition 18:58:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=974543 18:58:04 #info Proposed Freeze Exceptions, anaconda, NEW 18:58:10 tflink: the patches are not sent to anaconda-devel-list so technically not 'post'ed 18:58:11 +1 18:58:20 +1 FE 18:58:20 this is completely wrong behaviour and ought to be fixed 18:58:27 +1 FE 18:58:31 +1 18:58:35 +1 FE 18:58:36 +1 FE 18:59:12 shame to put it in this late, but otoh our 'multiboot uefi' story has never worked very well so unlikely to maek things worse 18:59:32 proposed #agreed 974543 - AcceptedFreezeException - This behavior of creating new EFI partitions is not correct and should be fixed. A tested fix would be considered past freeze 18:59:33 at some point we're going to run into the problem of what to do if there isn't enough space in the esp but we'll burn that bridge when we get to it 18:59:33 ack 18:59:49 ack 18:59:57 ack 18:59:59 ack 18:59:59 #agreed 974543 - AcceptedFreezeException - This behavior of creating new EFI partitions is not correct and should be fixed. A tested fix would be considered past freeze 19:00:00 ack 19:00:20 adamw: the files are very small, currently 19:00:46 #topic (974543) Anaconda is always creating new efi system partition 19:00:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=974543 19:00:52 #info Proposed Freeze Exceptions, anaconda, NEW 19:00:52 bah 19:00:55 #undo 19:00:55 Removing item from minutes: 19:00:57 #undo 19:00:57 Removing item from minutes: 19:00:58 #undo 19:00:58 Removing item from minutes: 19:00:59 can we squeeze https://bugzilla.redhat.com/show_bug.cgi?id=873207 in too? 19:01:06 #topic (873207) UEFI: No entry in grub2 menu for windows8 in dual boot setup install 19:01:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=873207 19:01:11 #info Proposed Freeze Exceptions, grub2, ASSIGNED 19:01:45 so, we have a fix for os-prober, but grub2 is still missing some pieces 19:02:01 and of course, the previous bug is blocking this 19:02:09 more or less 19:02:12 +1 we really should get UEFI multiboot working if we can. 19:02:47 I have to note that a possible grub2 change will require proper re-testing of even non-UEFI scenarios 19:02:51 +1 yeah 19:02:56 or os-prober change 19:03:03 proposed #agreed 873207 - AcceptedFreezeException - While not a blocker, getting UEFI multiboot would be very useful. A tested fix would be considered after freeze 19:03:11 we do still have time to get testing for non-uefi. 19:03:15 yes 19:03:16 ack 19:03:33 ack 19:03:43 ack 19:04:00 (it could be argued to be a blocker as the 'dual-boot with windows' criterion does not except UEFI, but ehhh) 19:04:17 #agreed 873207 - AcceptedFreezeException - While not a blocker, getting UEFI multiboot would be very useful. A tested fix would be considered after freeze 19:04:19 the other two mentioned bugs don't have any patches ready. leave for next time? 19:04:23 we should probably hard stop now, but could people maybe vote on the other two I highlighted in the reports? 19:04:36 kparal: right, but they could probably be fixed quickly and i'd really like to get the fixes in if/when they come 19:04:48 * kparal doesn't mind voting now 19:04:51 or just pull an hour tomorrow 19:05:08 Let's go ahead 19:05:13 we haven't touched the accepted blockers, so it might be better to stop for today 19:05:20 Ah 19:05:21 * jreznik would like to leave the office now, so is ok with some time tmrw 19:05:27 personally i can stick around but i don't want to start pushing the 'three hour hard stop' rule 19:05:34 * Viking-Ice to leave jreznik office 19:05:34 it's a good rule, let's not set it on fire 19:05:45 #topic Open Floor 19:05:50 So, when to meet again? 19:06:03 I heard a request for earlier than usual tomorrow 19:06:03 same time tomorrow? 19:06:12 works fine as well 19:06:18 13:00 UTC? 19:06:28 earlier would be better, sure, but it depends on when adamw wakes up :D 19:06:38 Aye 19:06:48 Depends on how much Angry Birds he's consumed 19:06:55 i can't go earlier than 15:00 UTC really 19:07:02 See? 19:07:05 that's 8am here 19:07:12 you really don't want to see me at 7 19:07:24 WURRRUBBBLEEE COFFEEEE 19:07:31 so, tomorrow @ 15:00 UTC? 19:07:31 not a problem later for me - just send reminder :) leaving now, thanks guys 19:07:33 adamw: I have seen you at 7AM 19:07:45 sounds good to me 19:08:16 #info since we didn't quite finish everything today, will meet again tomorrow @ 15:00 UTC to finish the lists 19:08:17 handsome_pirate: that's only when he doesn't go to sleep, that's an acceptable approach 19:08:37 if there's nothing else, I'll set the fuse 19:08:48 handsome_pirate: yeah, that's not 7am, that's 19 o'clock in the evening 19:08:49 kparal: Aye, I think Cards against Humanity ran late enough that was doable 19:09:02 :)) 19:09:03 time is relative 19:09:12 Lunchtime doubly so 19:09:15 Oh, wait 19:09:19 that's ' 19:09:23 that's 'time is an illusion' 19:09:37 Been too long since I've read those 19:09:45 my friend and I invented Relative Morning at college - Relative Morning is the three hours after you wake up, no matter when you wake up 19:09:49 * handsome_pirate goes off to dig his copy of H2G2 19:10:00 for the record viking beats pirate every day and decate 19:10:01 :) 19:10:01 heh 19:10:28 @fight pirate viking 19:11:11 Anyhow, thanks for coming everyone! 19:11:20 * tflink will send out minutes shortly 19:11:33 * tflink will send out minutes and continuation notice shortly 19:11:37 #endmeeting