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