17:00:04 <pschindl> #startmeeting F20-blocker-review
17:00:05 <zodbot> Meeting started Wed Dec  4 17:00:04 2013 UTC.  The chair is pschindl. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:07 <pschindl> #meetingname F20-blocker-review
17:00:07 <zodbot> The meeting name has been set to 'f20-blocker-review'
17:00:08 <pschindl> #topic Roll Call
17:00:22 * roshi is here
17:00:27 * mkrizek is here
17:00:40 * pwhalen is here
17:00:43 * satellit_ listening
17:00:54 * randomuser is here for now
17:01:02 <pschindl> #chair kparal roshi
17:01:02 <zodbot> Current chairs: kparal pschindl roshi
17:01:12 * kparal here
17:01:21 * danofsatx is present
17:01:24 <pschindl> Hi all. Welcome to the show :)
17:01:41 <cmurf> cmurf materializes from an energy cloud into matter
17:01:51 <pschindl> Ok. It looks like lot of people come. So let's start.
17:02:00 <pschindl> #topic Introduction
17:02:02 <pschindl> Why are we here?
17:02:04 <pschindl> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:02:06 <pschindl> #info We'll be following the process outlined at:
17:02:07 <pschindl> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:02:09 <pschindl> #info The bugs up for review today are available at:
17:02:11 <pschindl> #link http://qa.fedoraproject.org/blockerbugs/current
17:02:14 <pschindl> #info The criteria for release blocking bugs can be found at:
17:02:16 <pschindl> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
17:02:18 <pschindl> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
17:02:26 <pschindl> #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
17:02:26 <pschindl> #info 7 Proposed Blockers
17:02:27 <pschindl> #info 15 Accepted Blockers
17:02:27 <pschindl> #info 2 Proposed Freeze Exceptions
17:02:27 <pschindl> #info 14 Accepted Freeze Exceptions
17:02:51 <pschindl> Proposed blockers:
17:02:59 <pschindl> #topic (1026834) method= combined with 'url' in kickstart fails to find packages, in certain situations
17:03:01 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1026834
17:03:03 <pschindl> #info Proposed Blocker, anaconda, NEW
17:03:20 <cmurf> sounds familiar
17:03:52 <kparal> I'm growing tired of this. annoying bug, still changing
17:03:54 <kparal> heisenbug
17:04:19 <kparal> I can't really say if it can affect post-release users or not
17:04:45 <kparal> however, the workarounds are known
17:04:50 <pschindl> Heisenbug? I thing that those are allowed for F20, or not?
17:04:56 <kparal> so, we might keep it to FE
17:05:13 <kparal> pschindl: a bad choice for a release name then!
17:05:21 <kparal> who have voted for it, anyway?!
17:05:25 <cmurf> i did
17:05:30 <cmurf> did you see the other options?
17:05:33 <pschindl> me too :)
17:05:34 <kparal> me too. but that's not important!
17:05:46 <kparal> a bad choice still! :)
17:05:48 <cmurf> oh right, changing mind just like heisenbug
17:05:51 <cmurf> anyway i'm -1/+1
17:05:59 <cmurf> i'm a scant +1 FE
17:06:12 <pschindl> I'm -1/+1 too.
17:06:13 <kparal> this basically affects only virt-install users, because otherwise you use repo= and not method=
17:06:15 <cmurf> does FE in this case mean anything since it doesn't affect release media?
17:06:19 <kparal> (most probably)
17:06:38 <kparal> cmurf: it does, it can be included in future TCs/RCs
17:06:48 <kparal> otherwise it can't
17:07:08 <roshi> -1/+1
17:07:18 <nirik> -1/+1
17:07:20 <kparal> cmurf: it affects release media, it's an anaconda+dracut+yum bug
17:07:26 <cmurf> got it
17:07:33 <cmurf> combined with the user specifying method= instead of repo=
17:07:42 <kparal> yeah
17:08:09 <kparal> -1/+1 it is
17:08:37 <cmurf> would be nice to hear from James or Martin
17:08:40 <kparal> do we have a secretary?
17:08:54 <roshi> I can do it
17:09:05 <roshi> frees you up for the end of the meeting
17:09:06 <kparal> cmurf: I talked to Martin Kolman. there are probably bugs in multiple components that affect each other
17:09:11 <pwhalen> -1/+1
17:09:13 <cmurf> ick
17:09:14 <kparal> roshi: thanks
17:09:42 <cmurf> heisenmultibug
17:09:49 * ignatenkobrain is here
17:09:52 <mkolman> I am looking at it right now
17:10:01 <mkolman> it is indeed pretty convoluted
17:10:09 <kparal> pschindl: propose something along the lines of too many variables that need to occur to trigger this bug, which are hopefully not likely post-release
17:10:23 <ignatenkobrain> hi tflink, kparal, adamw, nirik, jreznik, roshi
17:10:26 <adamw> sory floks
17:10:32 <kparal> morning
17:10:34 <pschindl> proposed #agreed 1026834 - RejectedBlocker AcceptedFreezeException - Non-functional method affects only virt users and post-release users won't be probably affected. Rejected as blocker but it's consider as FE
17:10:41 <adamw> they're shutting our water off today so had to go take a quick shower...
17:10:52 <adamw> ack
17:11:00 <cmurf> ack
17:11:01 <mkrizek> ack
17:11:08 <kparal> ack
17:11:15 * jreznik has another meeting running now
17:11:18 <pschindl> #agreed 1026834 - RejectedBlocker AcceptedFreezeException - Non-functional method affects only virt users and post-release users won't be probably affected. Rejected as blocker but it's consider as FE
17:11:23 <roshi> morning ignatenkobrain
17:11:34 <pschindl> #topic (1037626) AttributeError: can't set attribute
17:11:36 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1037626
17:11:38 <pschindl> #info Proposed Blocker, anaconda, MODIFIED
17:11:42 <pschindl> #chair adamw
17:11:42 <zodbot> Current chairs: adamw kparal pschindl roshi
17:11:43 <ignatenkobrain> morning ? seriosly ? :D
17:11:49 <ignatenkobrain> 21:11 PM
17:11:51 <roshi> oh yeah
17:11:53 <roshi> lol
17:11:58 <adamw> ignatenkobrain: he was jus a bit early!
17:12:03 <cmurf> this is really straight forward i think
17:12:09 <kparal> +1 blocker
17:12:20 <kparal> text install broken
17:12:28 <adamw> +1
17:12:29 <ignatenkobrain> +1
17:12:30 <pschindl> +1
17:12:35 <cmurf> yes +1, but strange for it to have regressed like this
17:13:57 <mkrizek> +1
17:14:26 <pschindl> proposed #agreed 1037626 - AcceptedBlocker - Broken text installation violates final criterion: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
17:14:29 <ignatenkobrain> this is ANACONDA! :P
17:14:31 <ignatenkobrain> ack
17:14:54 <mkrizek> ack
17:14:57 <roshi> +1 ack
17:15:05 <adamw> ack
17:15:13 <pschindl> #agreed 1037626 - AcceptedBlocker - Broken text installation violates final criterion: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
17:15:13 <kparal> ack
17:15:18 <pschindl> #topic (1037767) Text install : Error in sys.excepthook
17:15:20 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1037767
17:15:22 <pschindl> #info Proposed Blocker, anaconda, POST
17:15:37 <cmurf> last comment suggests this is a dup of the one we just agreed is a blocker
17:15:49 <ignatenkobrain> +1 from me, text install the same
17:15:53 <cmurf> if it is a dup we should mark it as a dup of that one
17:15:53 <adamw> huh, i thought that was this bug :P
17:15:55 <cmurf> otherwise +1
17:15:58 * adamw not paying attention
17:16:01 <adamw> +1 cmurf
17:16:40 <ignatenkobrain> actually this is another bug. but yes. broken text install
17:17:44 <kparal> in this bug python-meh crashed when trying to report the text install crash
17:17:46 <cmurf> looks like this could affect other archs
17:18:20 <kparal> I think this violates https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Failure_reporting
17:18:20 <adamw> so, hm
17:18:22 <roshi> punt until text inst is fixed
17:18:30 <adamw> kparal: yeah, i was about to suggest that.
17:18:35 <adamw> but it depends how often it fails, kinda.
17:18:39 * adamw looks at the patch
17:20:03 <mkolman> those two bugs look different to me
17:20:25 <adamw> mkolman: so to make sure we have the right understanding: 1037626 is the bug for text install being broken, yes?
17:20:38 <mkolman> adamw: yeah
17:20:48 <adamw> 1037767 covers python-meh failing in text mode because it tries to import gtk
17:20:54 <adamw> when reporting a crash that already happened
17:20:55 <mkolman> adamw: fix for it has been pushed
17:21:31 <kparal> +1 blocker per criteria, it would probably happen for any text-mode crash
17:21:32 <mkolman> 1037767 something else, yes
17:21:40 <adamw> kparal: still, does it stop people filing crashes?
17:21:42 <mkolman> *is something else
17:21:50 <adamw> it doesn't seem to, from the number of dupes on 1037626
17:22:05 <kparal> well I think python-meh crashes just on arm
17:22:09 <kparal> it definitely worked for me
17:22:24 <mkolman> well, I can try (if you go to TTY2 there are a few commands stored in history, one of them can be used to trigger an exception)
17:22:25 <kparal> pwhalen: is the bug reproducible on arm? crashes every time?
17:22:41 <pwhalen> kparal, it is
17:22:44 <adamw> urgh, now there's a tricky evaluation
17:22:54 <kparal> python-meh in x86_64 worked OK for me
17:22:55 * handsome_pirate stumbles in late
17:23:18 <adamw> so you can't accurately report crashes in text install on ARM? is that a reasonable evaluation?
17:23:19 <kparal> adamw: can you link the patch?
17:23:20 * Viking-Ice as well
17:23:29 <adamw> kparal: i may have written that on the wrong bug
17:23:34 * adamw goes to look at anaconda-patches-list
17:23:55 <pwhalen> adamw, right
17:24:31 <adamw> yeah, i think that applied to the 'broken text install' bug, not the 'broken python-meh' bug
17:24:56 <pwhalen> c2 says happens in x86 as well
17:25:32 <pwhalen> I did test x86 as well, I didnt see it myself.
17:25:40 <adamw> lnie may have meant she also saw the text install crash
17:25:49 <pwhalen> true
17:26:30 <adamw> mkolman: how invasive would it be to fix this?
17:26:45 <mkolman> that GTK one ?
17:26:50 <adamw> yeah
17:27:06 <adamw> and is the evaluation 'you can't report any crashes in text mode on ARM' accurate? (pwhalen?)
17:27:27 <pwhalen> adamw, yes
17:27:29 <mkolman> not really sure, vpodzime is the python-meh guy
17:28:01 <pschindl> I'm +1. ARM is primary arch and this one violates criterion.
17:28:09 <adamw> yeah, it would be pretty ugly to wave this one away
17:28:10 <mkolman> but I guess one could just check if textmode is running and don't import it - could trigger other exceptions though
17:28:16 <roshi> +1
17:28:19 <adamw> pwhalen: has it been broken through f20 cycle or it recently broke?
17:28:51 <pwhalen> text installs have always worked, so this is the first time encountering it
17:28:53 <cmurf> yeah i'm +1 also, better to get it set as a blocker in this case, and recind if it turns out we're mistaken
17:28:54 <mkolman> for the record, plain TUI seems to be working at the moment
17:29:00 <mkolman> will try the exception handling
17:29:07 <mkolman> (on x86_64
17:29:09 <mkolman> )
17:29:21 <pschindl> proposed #agreed 1037767 - AcceptedBlocker - Reporting failures on ARM violates criterion: "The installer must be able to report failures to Bugzilla, with appropriate information included."
17:29:31 <ignatenkobrain> ack
17:29:34 <cmurf> ack
17:29:37 <pwhalen> ack
17:29:42 <roshi> ack
17:29:48 <kparal> ack
17:29:53 <pschindl> #agreed 1037767 - AcceptedBlocker - Reporting failures on ARM violates criterion: "The installer must be able to report failures to Bugzilla, with appropriate information included."
17:29:58 <adamw> ack
17:29:59 <Viking-Ice> ack
17:30:05 <pschindl> #topic (1037934) 'unable to allocate aligned partition' errors keep occurring when trying to create partitions on iSCSI device, and does...other...odd...stuff
17:30:07 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1037934
17:30:09 <pschindl> #info Proposed Blocker, anaconda, NEW
17:30:12 <pschindl> I'm too quick, sorry :)
17:30:20 <adamw> =)
17:30:31 <adamw> this is the kinda professional bug report adamw turns out at midnight
17:31:05 <adamw> tflink tested it and it worked for him, and it doesn't work for me on f19 either
17:31:06 <Viking-Ice> lost yourself at the summary ey
17:31:12 <adamw> so probably reasonable to say -1
17:31:20 <Viking-Ice> why
17:31:28 <adamw> likely some kind of wackiness with my particular iSCSI config
17:31:34 <cmurf> looks intermittant
17:31:36 <handsome_pirate> adamw:  Not hitting this
17:31:44 <cmurf> and if you fiddle with it, it eventually works
17:31:47 <cmurf> but does seem wonky
17:32:05 <adamw> if we look like we're slipping anyway, though, we could punt on it till dlehman or someone takes a look and figures out what the trigger is
17:32:09 <Viking-Ice> for the first is this a) supposed to work b) be blocking
17:32:25 <Viking-Ice> adamw, you probably need andy for this one
17:32:32 <adamw> cmurf: if all iscsi installs behaved like mine, i'd be strongly +1 - it's broken enough to really not be considered workable - but that doesn't seem to be the case
17:32:49 <adamw> handsome_pirate: you tried an iSCSI install and it worked for you too? can you add a comment?
17:32:58 <adamw> Viking-Ice: and, yeah, a) and b) are both true
17:32:59 <cmurf> well we do have a small sample size
17:33:05 <mkolman> <offtopic>just successfully tested exception handling & filled a testing bug in TUI @ x86_64</offtopic>
17:33:11 * jreznik is here, sorry for missing part of the meeting - but I'm leading one call and it's impossible to multitask :D
17:33:20 <adamw> cmurf: if pirate's install worked it's 2:1 for 'success', which is comfortably above fedora standards ;)
17:33:41 <handsome_pirate> adamw:  Will do
17:33:41 <roshi> lol
17:33:47 <cmurf> i'd like to see a working storage.log posted
17:33:59 <adamw> yeah, me too, i'd like to see how those bits look when it works properly
17:34:09 <roshi> -1 or punt
17:34:13 <cmurf> and a clean failure storage.log
17:34:15 <Viking-Ice> punt for more data
17:34:26 <handsome_pirate> adamw:  I can confirm it works for both x86_64 and arm
17:34:27 <cmurf> and ping andy
17:34:30 <cmurf> all at the same time
17:34:33 <adamw> cmurf: what do you mean 'clean' exactly?
17:34:41 <adamw> handsome_pirate: cool, that's a big help
17:34:49 <adamw> and which andy are we talking about?
17:34:51 <ignatenkobrain> +1 from me
17:35:11 <adamw> and is anyone secretarializing, or shall I do it?
17:35:17 * roshi is
17:35:19 <adamw> yay
17:35:29 <cmurf> adamw: nevermind, i meant clean as in less fiddling but it sems to be fiddling that eventually makes it work
17:35:30 <roshi> I mean, if you want it
17:35:32 <roshi> :p
17:36:19 <pschindl> roshi: thanks for secretar...... thing :)
17:36:27 <roshi> so, two punt votes, one blocker
17:36:31 <roshi> np :)
17:36:34 <kparal> punt
17:36:43 <pschindl> punt from mee too
17:36:44 <danofsatx> punt
17:37:06 <pschindl> ok, let's punt
17:37:13 <ignatenkobrain> ж)
17:37:15 <ignatenkobrain> ;)
17:37:32 <roshi> that looks kinda like a hadoken
17:37:38 <roshi> </offtopic>
17:38:01 <pschindl> #info 1037934 - needs more information. Now it's 2:1 against bug. Punt for more information.
17:38:18 <pschindl> #topic (881624) U.S. keyboard layout used for encryption passphrase entry during fedup second phase
17:38:20 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=881624
17:38:22 <pschindl> #info Proposed Blocker, fedup, NEW
17:39:22 <ignatenkobrain> interesting bug..
17:39:29 <adamw> so we rejected this for f19 before
17:39:45 <adamw> someone wanted to re-propose it for 20 beta but there's a bug in the blocker proposal app which meant it was considered rejected
17:40:09 <adamw> so i threw it on the list for today for formality's sake. kinda expecting -1 again, though, it would be the consistent call. it is kinda a crappy bug, though.
17:40:20 * adamw goes to find the log where we rejected it
17:40:35 <ignatenkobrain> adamw: have we workaround ?
17:40:38 <Viking-Ice> +1 blocker
17:40:55 <adamw> ignatenkobrain: 'figure out how to type your passphrase with a US layout'
17:40:56 <cmurf> well it seems really late in the process and a complicated bug to fix
17:41:04 <kparal> we rejected it because we expected it to be fixed post-release
17:41:16 <adamw> kparal: ah, yeah. we really need a way to track those.
17:41:23 <Viking-Ice> well obviously it did not get fixed postreleas
17:41:26 <Viking-Ice> after all this time
17:41:26 <adamw> and beat wwoods over the head with them.
17:41:33 <kparal> a good way to track would be to use FinalBlockers
17:41:47 <Viking-Ice> and a good way to get this fixed is to actually block on it
17:41:55 <adamw> kparal: i disagree strongly with your application of the term 'good' :P
17:42:02 <ignatenkobrain> -1 from me, but should re-view in f21
17:42:21 <kparal> right, in 6 months let's read this one again :)
17:42:23 <Viking-Ice> bullshit we block on this bug now or we take it of the radar for good
17:42:23 <jreznik> we are really getting hit with such kind of bugs coming every release :( once it's out of blocker radar...
17:42:26 <ignatenkobrain> if will stay not fixed - add as blocker
17:42:42 <handsome_pirate> adamw:  wwoods is one floor below me if he needs beating
17:42:44 <adamw> http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-03/f18_final_gono-go_meeting.2013-01-03-17.01.log.txt is the log of previous discussion , search '881624' to find it
17:42:45 <nirik> -1 here for f20. but is the bug actually in fedup?
17:42:47 <roshi> +1 blocker - it shouldn't go two releases
17:42:52 <adamw> handsome_pirate: grab a bat and whale away
17:42:57 <Viking-Ice> roshi,  right
17:43:02 * handsome_pirate is +1 blocker
17:43:37 <kparal> I haven't found the info why this is relevant for F19->F20. shouldn't F19 contains correct vconsole option on the kernel cmdline?
17:43:42 * adamw is worried about opening the gateway to indefinite slipsville, but i also think it's a really sucky bug
17:43:43 <pwhalen> -1 for f20, attack it early in f21
17:43:56 <Viking-Ice> pwhalen, failed last time
17:43:56 <ignatenkobrain> pwhalen: alright
17:44:09 <roshi> I would be for that pwhalen, but who's going to take it? And actually *fix* it this time around
17:44:10 <adamw> kparal: i thought i hit it in testing 19->20 last night, but it may have been a messy test, i should probably do it again
17:44:15 <jreznik> kparal: anyone to try to investigate?
17:44:16 <Viking-Ice> adamw, we need to start freeing up resources and getting rid of re-occuring bugs is one way to achive that
17:44:21 <kparal> adamw: was it a clean F19 install?
17:44:25 <adamw> while we discuss it, let me run a test with only a non-US layout selected in anaconda
17:44:29 <cmurf> i wonder if the really sucky bug needs a feature since it seems to have multiple components involved rather than a hasty fix that we're unsure of and won't likely get much testing
17:44:32 <adamw> kparal: yes, but i had two layouts selected in f19 anaconda
17:44:39 <adamw> kparal: and it may have written the wrong one to vconsole
17:45:03 <pschindl> Ok, if I found all votes it is +3 - 3 = 0. So any other votes?
17:45:05 <greenlion_> won't the fix for bug break on layouts that does not contain latin characters? (like russian layout)
17:45:30 <handsome_pirate> pschindl:  I'm +1 blocker
17:45:36 <adamw> greenlion_: that's one of the tricky bits. it's a complex bug, and i'd have to remember how f19 behaved in that case...
17:45:40 <nirik> IMHO, it needs more investigation as to who is at fault. It's not clear to me that it's fedup... could be systemd, dracut, dunno
17:45:44 <cmurf> pschindl: i'm a -1 for now
17:45:51 <kparal> I would like to make sure that this is really broken for F19 (clean install)->F20. it if is, I'm +1 blocker. it this only affects older installation (upgraded again and again), I wouldn't block on it
17:46:03 <cmurf> i'm with nirik
17:46:38 <adamw> it would probably be easier to investigate and ensure correct behaviour if we reset and re-evaluate from f20 to f21, because we've made keyboard layout handling in anaconda and kbd and xkb a lot better in f20, but that doesn't help existing users
17:46:41 <Viking-Ice> nirik, most likely so yes and or dracut
17:46:48 <nirik> which also makes it unclear if it can be fixed in f19 fedup, or needs an actual fix in f20... or if that fix has to be in base repos or can be an update.
17:46:50 * adamw running an f19 clean install atm
17:47:14 <danofsatx> what criteria is qualifying it as a blocker?
17:47:27 <kparal> danofsatx: can't boot post-upgrade
17:47:34 <kparal> can't decrypt the disk
17:47:39 <danofsatx> ok, missed that one.
17:47:54 <cmurf> well underlying blocker is that it can actually be fixed, and be fixed in something approximating a not totally insane time frame
17:48:02 <adamw> it's not actually post-upgrade
17:48:08 <adamw> it's during-upgrade
17:48:13 <Viking-Ice> cmurf,  dont vote on time frame
17:48:20 <Viking-Ice> if we need to slip we slip
17:48:21 * kparal missed that
17:48:31 <cmurf> i have no issue with one or two or maybe three slips
17:48:32 <adamw> when fedup finishes downloading packages and reboots to actually upgrade the system, it needs to unlock the disk at that point, obviously
17:48:35 <cmurf> IF we understand the bug
17:48:36 <cmurf> and the fix
17:48:44 <adamw> it's when you go to enter that passphrase that you hit the bug
17:48:46 <cmurf> but not 4 5 or 6 slips just for one bug
17:48:58 <Viking-Ice> ?
17:49:00 <adamw> cmurf: right, that's my concern too, but on the other hand, we can always reverse the decision
17:49:06 <nirik> right, so if you can't do it there, you can at least go back to your working f19 system
17:49:08 <kparal> adamw: so the upgraded system contains correct vconsole in all cases? it's just the upgrade process that's wrongly configured?
17:49:09 <adamw> if it turns out to be impractical to fix sanely
17:49:17 <Viking-Ice> cmurf, if we need to slip we slip for the time it takes to fix the thing that was slipped for
17:49:29 <adamw> kparal: it may be broken post-install too, at this point i'll wait for the result of my test (and i'll check what's actually set in f19 before doing the upgrade)
17:49:33 <Viking-Ice> kparal, dracut
17:49:45 <Viking-Ice> or rather dracut + fedup
17:49:46 <cmurf> hence why i'd like to understand the scope of the bug
17:49:48 <nirik> perhaps we come back to this with more info?
17:49:57 <nirik> (after adamw's testing?)
17:50:06 * adamw booting to the installed f19 system now
17:50:13 <adamw> i'm using a minimal install, so it shouldn't take long.
17:50:15 <ignatenkobrain> adamw: w/ crypto ?
17:50:20 <adamw> yes. of course.
17:51:03 <ignatenkobrain> so. waiting adamw for testing ?
17:51:39 <cmurf> oh my god coffee time!
17:51:49 <Viking-Ice> good idea take 5
17:52:07 * cmurf pounces on deity beans
17:52:45 <adamw> hah, weaklings - we haven't even been going for an hour yet...
17:53:55 <adamw> i don't mind going to next bug and coming back, or you guys waiting. either way.
17:54:09 <pschindl> ok. So could you vote now for +1/-1/punt please.
17:54:16 <roshi> just put your coffee making next to your monitor
17:54:25 <pwhalen> I say move on for now
17:54:26 <adamw> pschindl: ?
17:54:59 <pschindl> adamw: I just want to move forward.
17:55:09 <jreznik> move to another bug now
17:55:14 <adamw> pschindl: you can move on to the next bug and then move back to this one later
17:55:17 <adamw> doesn't really need a vote
17:55:19 <jreznik> pschindl: we want to hear from adamw first
17:55:29 <pschindl> ah, ok :)
17:55:37 <pschindl> sry. I'm a bit confused :)
17:55:49 <pschindl> #topic (1036961) Setting up bridge via NetworkManager gui in Gnome fails
17:55:51 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1036961
17:55:53 <pschindl> #info Proposed Blocker, NetworkManager, NEW
17:56:20 <ignatenkobrain> oh
17:56:29 <kparal> it would be nice it this worked, but it's not really essential functionality
17:56:33 <kparal> it's a new feature
17:56:57 <kparal> no logs attached
17:56:58 <adamw> yeah, my instinct is -1, it's a bit of a stretch to consider this 'panel functionality'
17:56:59 <kparal> -1
17:57:03 <jreznik> -1
17:57:03 <ignatenkobrain> -1 too
17:57:11 <mkrizek> -1
17:57:17 <cmurf> default panel functionality no less
17:57:20 * handsome_pirate is here
17:57:23 <cmurf> -1
17:57:30 <nirik> -1 (although I sure wish it worked someday)
17:57:31 <ignatenkobrain> but could be good if NM will have support bridges :D
17:57:39 <handsome_pirate> alas, as it is my bug, I am +1
17:57:40 <handsome_pirate> :)
17:57:51 <adamw> you're allowed to change your mind :P
17:58:01 <ignatenkobrain> actually NM works w/ bridges very bad
17:58:05 <kparal> handsome_pirate: add logs, at leasat
17:58:05 <greenlion_> ignatenkobrain, NM promises to support bridges since F-12 :)
17:58:07 <roshi> is it just the GUI that doesn't let you do briding?
17:58:08 <kparal> *least
17:58:17 <handsome_pirate> kparal:  That's just it, there weren't any
17:58:21 <ignatenkobrain> greenlion_: but actually.....
17:58:27 <Viking-Ice> -1
17:58:28 <kparal> handsome_pirate: journalctl
17:58:28 <handsome_pirate> roshi:  Indeed
17:58:37 <roshi> hrm
17:58:45 <pwhalen> -1
17:58:55 <handsome_pirate> kparal:  Actually, I check
17:58:56 <handsome_pirate> ed
17:58:59 <ignatenkobrain> My opinion: should be fixed (as all bugs), but can't be as release blocker
17:59:11 <Viking-Ice> this stuffs going to be thrown out in F21 anyway so ;)
17:59:15 <pschindl> proposed #agreed 1036961 - RejectedBlocker - Non-functional bridge NetworkManager setting is not considered as essential funcionality.
17:59:24 <ignatenkobrain> ack
17:59:30 <mkrizek> ack
17:59:31 <pwhalen> ack
17:59:34 <adamw> ack
17:59:40 <roshi> ack
17:59:44 <kparal> ack
17:59:47 <pschindl> #agreed 1036961 - RejectedBlocker - Non-functional bridge NetworkManager setting is not considered as essential funcionality.
17:59:47 <Viking-Ice> ack
17:59:52 <handsome_pirate> Ah, well
17:59:53 <handsome_pirate> I tried
18:00:00 <cmurf> it should work
18:00:01 <handsome_pirate> If it doesn't work, why put it in?
18:00:02 <cmurf> it is a bug
18:00:13 <pschindl> #topic (1037688) /root has 755 permissions - should be 550
18:00:15 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1037688
18:00:17 <pschindl> #info Proposed Blocker, rootfiles, MODIFIED
18:00:22 <nirik> +1
18:00:31 <jreznik> +1
18:00:34 <Viking-Ice> +1
18:00:37 <ignatenkobrain> heh! +1
18:00:42 <cmurf> +1
18:00:43 <mkrizek> +1
18:01:19 <pwhalen> +1
18:02:00 <cmurf> unanimous
18:02:29 <jreznik> ovasik is on it
18:03:02 <adamw> yeah, or i can do the build if he doesn't
18:03:03 <adamw> +1
18:03:07 <Viking-Ice> ovasik the arm wrestler I believe ;)
18:03:10 <kparal> haha, thanks for telling me. I just installed F20 on my production system
18:03:13 <kparal> +1
18:03:27 <kparal> it really has 755 for /root
18:03:27 <greenlion_> there is already update - https://admin.fedoraproject.org/updates/rootfiles-8.1-16.fc20
18:03:35 <pschindl> proposed #agreed 1037688 - AcceptedBlocker - Wrong /root permission on livecd is considered to block.
18:03:37 <ignatenkobrain> ack
18:03:37 <pschindl> patch?
18:03:38 <roshi> all installed systems do
18:03:48 <roshi> what criteria for that one?
18:03:55 <kparal> security
18:03:59 <jreznik> roshi: sec
18:04:15 <roshi> I don't really see the security hole here
18:04:52 <ignatenkobrain> roshi: I think all security bugs should be fixed before release. anyway
18:05:33 <ignatenkobrain> + this bug was fixed.
18:05:42 <roshi> I concur ignatenkobrain
18:06:44 <handsome_pirate> +1
18:06:48 <cmurf> get outta my root folder, world!
18:07:11 <adamw> roshi: it's not an obvious exploit hole, it's just unexpected behaviour that could cause badness
18:07:27 <adamw> roshi: sysadmins may well expect /root to be a private space and dump stuff there that users shouldn't be able to see
18:07:39 <cmurf> it's about the last digit for "everyone" which is a 5 and is changing to a 0
18:07:39 <roshi> if they expect that shouldn't they check?
18:07:47 <danofsatx> just a point of note - openSUSE has 700 on /root
18:07:56 <adamw> roshi: they SHOULD, sure. and everyone should get their flu shot.
18:07:57 <roshi> since other distros do similar things
18:08:00 <cmurf> roshi: no root is like god, powerful, but often clueless
18:08:06 <adamw> danofsatx: it's the last byte that's the key one here. 0 good, 5 bad.
18:08:07 <roshi> the flu shot is a farce :P
18:08:17 <adamw> well, yaknowwhatimean
18:08:20 <roshi> lol
18:08:25 <adamw> there's also a practical consideration here
18:08:27 <danofsatx> adamw: I know, I was just tossing out a comparison
18:08:43 <ignatenkobrain> danofsatx: we're not openSUSE. we're Fedora! ;)
18:08:47 <Viking-Ice> uhum let's move on shall we
18:08:50 <pwhalen> I think its an expectation that the perm would be 0, not something that should be checked
18:08:50 <adamw> which is that if we choose not to block on (or even worse, ship with) a 'security bug' like this, the low end of the linux media loses its little mind
18:08:57 <roshi> yeah - I don't have any objections
18:08:57 <adamw> FEDORA DOESN'T CARE ABOUT SECURITY blahblahblah
18:09:16 <jreznik> secuwhat?
18:09:23 <ignatenkobrain> adamw: s/.*/blahblahblah/g
18:09:28 <roshi> sorry to drag this bug conversation out
18:09:31 <adamw> ignatenkobrain: :P
18:10:05 <adamw> we can go back to the layout bug if you like after this
18:10:21 <cmurf> you haz info?
18:10:23 <adamw> yeah
18:10:25 <ignatenkobrain> or :%s/.*/blahblahblah/g
18:10:35 <ignatenkobrain> pschindl: summary of this bug ?
18:11:05 <pschindl> proposed #agreed 1037688 - AcceptedBlocker - Wrong /root permission is a security bug thus considered to block.
18:11:06 <roshi> patch
18:11:24 <roshi> proposed #agreed 1037688 - AcceptedBlocker - Wrong /root permission on livecd is considered to violated Final Security criteria: "The release must contain no known security bugs of 'important' or higher impact..."
18:11:31 <ignatenkobrain> ack
18:11:32 <Viking-Ice> ack
18:11:34 <pwhalen> ack
18:11:36 <jreznik> ack
18:11:37 <nirik> ack
18:11:38 <pschindl> ack
18:11:43 <cmurf> ack
18:12:02 <kparal> ack
18:12:09 <ignatenkobrain> nxt ?
18:12:13 <pschindl> #agreed 1037688 - AcceptedBlocker - Wrong /root permission on livecd is considered to violated Final Security criteria: "The release must contain no known security bugs of 'important' or higher impact..."
18:12:24 <pschindl> ok. So that's all from proposed blockers
18:12:33 <pschindl> now freeze exceptions.
18:12:37 <cmurf> nope
18:12:42 <cmurf> go back to the layout bug
18:12:47 <cmurf> adam has info
18:12:50 <pschindl> cmurf: thx :)
18:12:59 <pschindl> #topic (881624) U.S. keyboard layout used for encryption passphrase entry during fedup second phase
18:13:01 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=881624
18:13:03 <pschindl> #info Proposed Blocker, fedup, NEW
18:13:14 <ignatenkobrain> .fire adamw
18:13:14 <zodbot> adamw fires adamw
18:13:27 <adamw> yo
18:13:28 <kparal> that was sneaky
18:13:29 <ignatenkobrain> adamw: dude! fix zodbot!!!!
18:13:36 <adamw> sorry, i'm typing up a comment in the bug
18:13:41 <adamw> it explains EVERYTHING
18:13:42 <Viking-Ice> type faster!
18:13:45 <adamw> better than doing it twice
18:14:16 <kparal> pschindl: that's not a FE
18:14:31 <kparal> or am I having deja-vu?
18:14:55 <kparal> oh, I get it now. we're back at adamw's bug
18:14:57 <ignatenkobrain> kparal: IIRC we have not voted for this
18:15:02 <ignatenkobrain> alright
18:15:04 <cmurf> correct
18:15:27 * cmurf vaguely hears elevator music
18:16:09 <ignatenkobrain> offtop: have we fedora radio ? :D
18:16:16 <cmurf> hmm yes it's Christmas Muzak
18:16:35 <cmurf> please adamw end the torture!
18:16:36 <roshi> +1 blocker
18:16:50 <adamw> ok, comment types
18:16:52 <adamw> d
18:16:55 * pwhalen hears the audio testcase music
18:17:00 <cmurf> roshi do you have some preview of adamw's imminent comment?
18:17:03 <ignatenkobrain> roshi: after all let me do: s/-/+/g :D
18:17:10 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=881624#c50
18:17:22 * ignatenkobrain reading
18:17:27 <adamw> it boils down to: yes, the bug happens on a very clean test, and I think I know why - no layouts in fedup's initramfs
18:17:38 <Viking-Ice> same as I had suspected
18:18:02 <Viking-Ice> and if that's missing there are probably few other things missing from that initramfs image
18:18:07 <Viking-Ice> ...
18:18:09 <ignatenkobrain> adamw: dracut-related problem ?
18:18:14 <Viking-Ice> fedup
18:18:17 <roshi> no cmurf, I don't
18:18:18 <roshi> lol
18:18:28 <adamw> Viking-Ice: wouldn't surprise me, and could possibly explain some other fedup bugs, i guess
18:18:30 <Viking-Ice> fedup should regenare the image ( anaconda should do that as well after install )
18:18:39 <adamw> Viking-Ice: anaconda now does
18:18:41 <adamw> in f20
18:18:44 <cmurf> interesting
18:18:46 <adamw> we could probably steal that code for fedup
18:18:50 <Viking-Ice> adamw, oh they fixed it
18:18:53 <kparal> fedup shoud use nohostonly initrd
18:19:02 <adamw> kparal: it's not even a hostonly initramfs
18:19:19 <adamw> the 3.11 kernel (the 'post-update' kernel) in my test is a hostonly initramfs, the 3.9 kernel (the one i got from anaconda) is generic
18:19:20 <Viking-Ice> I 'm still +1 wwoods can just copy paste and fix this
18:19:23 <adamw> generic has *all* kbd layouts
18:19:31 <adamw> hostonly has *only the one from vconsole.conf*
18:19:35 <adamw> fedup's has *none at all*
18:19:44 <Viking-Ice> merrry xmas
18:19:46 <kparal> for reliability sake, it should use a nohostonly initrd anyway
18:19:53 <cmurf> right
18:20:03 <adamw> kparal: that seems a reasonable approach. yeah
18:20:19 <Viking-Ice> kparal, consistent behavior nr1 nr2 nr3 )
18:20:22 <Viking-Ice> :)
18:20:35 <ignatenkobrain> adamw: what do you say now ? + or - ?
18:20:39 <cmurf> fedup generates its own initramfs correct?
18:20:43 <adamw> but anyway, unless i messed up somewhere, i think we now know the bug is definitely still there, doesn't seem to be specific to any corner case, and we roughly know the cause
18:20:54 <adamw> cmurf: that was the next thing i was gonna look at'
18:20:58 <adamw> maybe we can get will in here
18:21:01 <kparal> and it seems broken for any non-us layout
18:21:15 <cmurf> i was just going to suggest wwoods
18:21:17 <cmurf> ping
18:21:22 <kparal> unless the user password it the same as on us keyboard
18:21:25 <kparal> by chance
18:21:33 <cmurf> so i'm increasingly +1 now that this is better understood
18:21:35 <Viking-Ice> it's a clear blocker
18:21:51 <adamw> yeah, as of right now my inclination would be that we really ought to block on this
18:22:01 <ignatenkobrain> ah...
18:22:08 <cmurf> if it's just a matter of keymaps going into the initramfs, that's an easy fix if it gets all keymaps in a generic initramfs
18:22:12 <cmurf> and low risk
18:22:19 <adamw> for people whose passphrase contains ASCII characters it's a major annoyance, for people who use non-ASCII characters (they apparently exist) it's basically a roadblock
18:22:42 <Viking-Ice> the fact is if any country that has good beer does not have us keyboard layout so if anyone wants to actually drink good beer again vote yes ;)
18:22:52 <cmurf> nothing like umlauts in your passphrases
18:22:57 <ignatenkobrain> I'm still w/ -1
18:23:31 <pschindl> Viking-Ice: +1 :D
18:23:34 <cmurf> we should do a revote for pschindl and also ping wwoods
18:23:39 <cmurf> i've switched from -1 to +1
18:23:41 <pwhalen> I'll +1 now, fix should be easy enough
18:23:49 <kparal> +1
18:23:49 * adamw pinged wwoods
18:23:51 * roshi is still +1
18:23:55 <adamw> we can always re-consider it later, but +1 for now
18:23:57 <mkrizek> +1
18:24:35 <cmurf> that's +6/-1 ?
18:24:36 <pschindl> Can someone help with a criterion? :)
18:25:04 <jreznik> +1 and seems like we can deal with it (unless more bugs would be found once initramfs is fixed)
18:25:28 <adamw> on booting the upgraded system, btw, UK keymap is used correctly.
18:26:14 <cmurf> would be interesting to spoof the reboot to the systemd upgrade unit and inject a generic initramfs to see if that actually fixes the problem
18:26:32 <roshi> https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Upgrade_requirements maybe, pschindl
18:26:39 <adamw> cmurf: yeah, that would be my next stop (fiddle with the initramfs for fedup and see if i can fix it)
18:26:44 <pschindl> proposed #agreed 881624 - AcceptedBlocker - With this bug people with non-US keyboard won't be able to upgrade. Violates criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. "
18:26:45 <greenlion_> using umlauts in password is like... shooting oneself in foot
18:26:52 <pschindl> roshi: Thanks
18:26:53 <adamw> pschindl: yeah, it's a conditional violation of the upgrade criterion
18:26:58 <adamw> ack
18:27:00 <roshi> np
18:27:01 <kparal> ack
18:27:01 <roshi> ack
18:27:04 <ignatenkobrain> ack
18:27:08 <jreznik> ack
18:27:15 <pwhalen> ack
18:27:18 <cmurf> fedup might still be calling new-kernel-pkg which then creates the initramfs
18:27:25 <pschindl> #agreed 881624 - AcceptedBlocker - With this bug people with non-US keyboard won't be able to upgrade. Violates criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. "
18:27:27 <ignatenkobrain> EvilPinokioitself w/ non-US kbd
18:27:43 <pschindl> ok, so finaly. Proposed blockers are over.
18:28:04 <pschindl> I'm leaving now. So, kparal, could you take it from now?
18:28:11 <kparal> pschindl: sure
18:28:41 <kparal> accepted blockers now?
18:28:53 <pschindl> kparal: Thank you. There are proposed FE just for you, so you don't have to be sad that you have to do only accepted things :)
18:28:59 <pschindl> kparal: proposed FE
18:29:00 <roshi> proposed FE's, right?
18:29:04 <kparal> ah, sorry
18:29:12 <kparal> #topic (1037913) thunderbird in F20 stable incorrectly excludes arm  arches
18:29:12 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1037913
18:29:12 <kparal> #info Proposed Freeze Exceptions, thunderbird, MODIFIED
18:29:31 * pschindl is leaving. Bye.
18:29:50 <ignatenkobrain> +1 FE
18:29:50 <jreznik> +1 FE
18:29:56 <ignatenkobrain> pschindl: bye
18:30:01 <Viking-Ice> +1 FE
18:30:01 <adamw> +1
18:30:09 <kparal> +1 FE
18:30:16 <pwhalen> +1
18:30:23 <adamw> cmurf: so, https://github.com/wgwoods/fedup-dracut/
18:30:34 <cmurf> was just looking for that
18:30:48 <roshi> +1
18:30:51 <kparal> proposed #agreed 1037913 - AcceptedFreezeException - This will be considered as a freeze exception.
18:30:58 <Viking-Ice> ack
18:31:01 <pwhalen> ack
18:31:04 <ignatenkobrain> ack
18:31:04 <roshi> ack
18:31:15 <adamw> cmurf: moving to -qa
18:31:17 <kparal> #agreed 1037913 - AcceptedFreezeException - This will be considered as a freeze exception.
18:31:27 <kparal> #topic (1037789) Midori segfaults when using default search engine
18:31:28 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1037789
18:31:28 <kparal> #info Proposed Freeze Exceptions, webkitgtk, ASSIGNED
18:31:48 <Viking-Ice> -1/-1
18:32:21 <Viking-Ice> btw I thought our default search engine was google
18:32:32 <kparal> why -1?
18:32:35 <ignatenkobrain> nirik: webkitgtk ?
18:32:54 <nirik> it's a webkitgtk issue yes, seems to be only on arm.
18:33:02 <nirik> midori's default search engine is ddg
18:33:14 <adamw> Viking-Ice: fedora doesn't have a project-wide default
18:33:21 <ignatenkobrain> nirik: could we reproduce not w/ ddg ?
18:33:26 <adamw> Viking-Ice: browsers set their own
18:33:27 <kparal> will the update influence also intel archs?
18:33:44 <adamw> kinda a close call, you could fix this with an update without setting the world on fire
18:33:51 <adamw> though it'd be broken in the live forever
18:33:52 <nirik> ignatenkobrain: I don't know. I don't have an arm box with gui here.
18:34:06 <adamw> and Xfce is commonly used on ARM
18:34:08 <Viking-Ice> adamw, good point changing to +1 due to live
18:34:09 <adamw> so..probably +1 FE
18:34:20 <ignatenkobrain> -1
18:34:35 <pwhalen> +1 myself, would be nice to see this working again
18:34:37 <kparal> we have ARM Lives?
18:34:42 <nirik> I have no clue where the bug is yet...
18:34:48 <roshi> is it just arm?
18:35:08 <ignatenkobrain> adamw: on arm I think people using FF. not midori
18:35:24 <nirik> roshi: yes. Works fine here on x86
18:35:36 <Viking-Ice> webkitgtk <--- bug in
18:35:39 <adamw> kparal: sure
18:35:41 <roshi> -1 then - unless there is live arm images I don't know of
18:35:45 <adamw> kparal: well, not 'lives'
18:35:53 <adamw> but the pre-generated images...hm
18:35:54 <kparal> we have ARM images, and they are not read-only, they are updated as you run it
18:35:56 <adamw> yeah
18:36:00 <roshi> but you can update packages, right?
18:36:01 * adamw needs to stop doing 3 things at once
18:36:04 <ignatenkobrain> +3/-2 ?
18:36:10 <adamw> eh, still a tough call
18:36:32 <ignatenkobrain> nirik: jreznik?
18:36:41 <adamw> might be -1 now
18:36:43 <kparal> if this requires webkitgtk update, maybe the risk is not worth it
18:37:02 <adamw> still, it kinda looks like we have a week to test. :P
18:37:14 <Viking-Ice> if this is not being shipped by default on any image I'm back to -1
18:37:19 <kparal> there's no fix yet
18:37:42 * adamw and viking do the flip-flop dance
18:37:49 <adamw> it's like we're politicians!
18:37:51 <ignatenkobrain> actually we have more - instead of + ;)
18:38:10 <ignatenkobrain> adamw: take you deflope ;)
18:38:30 <pwhalen> it is default on the xfce image
18:38:38 * jreznik is not very responsible today :( needs at least on more cpu core
18:38:47 <adamw> pwhalen: but we don't have any immutable arm images, right? so it could be fixed with an update
18:38:57 <ignatenkobrain> jreznik: I can send you more cpus ;)
18:39:00 <nirik> it's default on the Xfce image.
18:39:03 <adamw> whereas if we pull something in to fix this and it busts it on x86 or something, then we _did_ break it in an immutable image...
18:39:09 <nirik> if thats not a blocking desktop on arm, then -1 blocker?
18:39:17 <adamw> nirik: we're on FE here
18:39:20 <Viking-Ice> let's pull it in then, if it turns out to be to invasive we simply skip it it's FE
18:39:20 <nirik> ah, ok.
18:39:21 <pwhalen> adamw, it could, I would be okay as an update
18:39:22 <adamw> it's not being considered for blocker
18:39:34 <nirik> note... gnome stuff mostly uses webkitgtk3
18:39:39 <nirik> which is a different package
18:39:49 <pwhalen> if the fix was ready, it would be nice to pull it in
18:40:14 <ignatenkobrain> kparal: results of this bug ?
18:40:34 * kparal waiting to reach some consensus
18:40:37 <nirik> pwhalen: I think I am going to have to build one with different flags to get useful debuginfo.
18:40:42 <Viking-Ice> at this point nobody knows what the problem really is right and shipping an browser with broken search engine to our amr userbase kinda sucks big time
18:40:42 <nirik> so I can get a useful trace
18:40:49 <Viking-Ice> mean arm
18:41:01 <nirik> pwhalen: is it just search? or does it crash other pages?
18:41:17 <nirik> or is it just ddg?
18:41:18 <kparal> Viking-Ice: a single yum update will fix that
18:41:24 <pwhalen> nirik, can test when you're ready.. seems to be just searches, can test more
18:41:43 <nirik> pwhalen: cool. can continue over on #fedora-arm or whatever.
18:41:47 <kparal> I'm mostly -1
18:41:54 <ignatenkobrain> kparal: consensus is not needed !
18:42:05 <Viking-Ice> kparal, it's an FE so ...
18:42:29 <nirik> pwhalen: oh, sigh. there's a new webkitgtk build... can you try it for grins?
18:42:42 <kparal> Viking-Ice: so... ?
18:42:53 <pwhalen> nirik, sure, will need to re-image, but will do
18:42:53 <jreznik> well, if it uses webkitgtk, not 3 it could be ok
18:43:01 <Viking-Ice> kparal, we dont have to pull it in...
18:43:34 <nirik> pwhalen: one of the webkitgtk comaintainers built a 2.2.3 this morning.
18:43:43 <Viking-Ice> in anycase the workaround is not that drastic type the url in the browser window
18:43:50 <Viking-Ice> for the search engine
18:44:07 <kparal> proposed #agreed 1037789 - AcceptedFreezeException - This will be considered as a freeze exception if the fix is timely and does not affect other architectures.
18:44:26 <roshi> ack
18:44:26 <ignatenkobrain> why accepted ?
18:44:30 <Viking-Ice> ack
18:44:31 <pwhalen> ack
18:44:41 <kparal> ignatenkobrain: because we can back out if we don't like it
18:44:48 <roshi> Viking-Ice has a point, we don't have to accept the fix
18:44:59 <roshi> that's why the accepted, AIUI
18:45:01 <ignatenkobrain> ok. ack
18:45:05 <kparal> but, usually adamw decides that when asking for a new TC
18:45:08 <adamw> ack
18:45:16 <adamw> kparal: if i'm unsure i'll consult with relevant people
18:45:27 <kparal> adamw: great, thanks
18:45:28 <jreznik> ack
18:45:29 <adamw> so yeah, my ack is a 'we might decide not to pull it' ack
18:45:34 <kparal> #agreed 1037789 - AcceptedFreezeException - This will be considered as a freeze exception if the fix is timely and does not affect other architectures.
18:45:52 <kparal> all from proposed FE
18:46:06 <kparal> shall we move to accepted blockers?
18:46:08 <adamw> sure
18:46:14 <kparal> ============================================================
18:46:14 <kparal> Accepted Freeze Exceptions
18:46:14 <kparal> ============================================================
18:46:18 <kparal> damn
18:46:24 <adamw> .fire kparal
18:46:24 <zodbot> adamw fires kparal
18:46:26 <kparal> ============================================================
18:46:27 <kparal> Accepted Blockers
18:46:27 <kparal> ============================================================
18:46:38 <kparal> #topic (1020974) incorrectly treats a disk with partially corrupt GPT as having no partition at all
18:46:38 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1020974
18:46:38 <kparal> #info Accepted Blocker, anaconda, ASSIGNED
18:47:28 <cmurf> works
18:47:34 <cmurf> no regressions
18:47:47 <jreznik> thanks cmurf for trying it
18:47:49 <Viking-Ice> there is always regression
18:47:50 <kparal> this seems to be almost done
18:47:51 <Viking-Ice> +1
18:48:06 <adamw> thanks for testing cmurf
18:48:13 <kparal> #info this is implemented and tested, we're waiting for a new build
18:48:19 <cmurf> it depends on parted/pyparted so i suspect a regression is possible but unlikely
18:48:20 <adamw> so we just need to get the update out and tc5 built, that's on me
18:48:41 <cmurf> it's not like the detection code for this bug is all new
18:48:56 * kparal moving on
18:49:07 <kparal> #topic (1027947) Cannot change a partition's size, then return it to the original size
18:49:08 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1027947
18:49:08 <kparal> #info Accepted Blocker, anaconda, ASSIGNED
18:49:22 <danofsatx> I just confirmed that this is fixed in TC4.
18:49:31 <kparal> and I confirmed it isn't
18:49:42 <roshi> I don't need to secretarialize anything for 1020974, do I?
18:49:50 <kparal> c28 use case is still broken
18:49:51 <roshi> since nothing changed, really?
18:49:56 <danofsatx> kparal: then what did we do different?
18:50:12 <kparal> danofsatx: have you tried to follow comment 0 or comment 28?
18:50:31 <kparal> comment 14 or 28, rather
18:50:48 <adamw> roshi: nah
18:50:58 <kparal> c14 was fixed, c28 still not
18:51:00 <roshi> thanks adamw for the sanity check
18:51:02 <kparal> according to my testing
18:51:05 <adamw> so, it's worth explicitly configuring whether we still think this is a blocker
18:51:05 <danofsatx> comment 28
18:51:23 <jreznik> adamw: at least, it's not crasher no more
18:51:26 <adamw> it was accepted as a blocker back when anaconda was crashing
18:51:29 <adamw> now it's just behaving kinda wackily
18:51:37 <adamw> do we still think it's a blocker?
18:51:45 <kparal> danofsatx: hum, ok. something is different, then
18:51:55 <adamw> we really should've filed a new bug report for the new behaviour, but that ship has sailed i think...
18:52:06 <jreznik> yep
18:52:08 <Viking-Ice> +1 blocker
18:52:36 <kparal> oh. initially, it hasn't crashed when following c28. but when I tried it just right now with TC4, it did crash
18:52:42 <kparal> I haven't realized
18:52:49 <kparal> so something is still fishy there
18:52:56 <kparal> I'll add more info after the meeting
18:53:18 <jreznik> ah, ok
18:53:24 <danofsatx> weird, I can't reproduce either of the errors with TC4 in VMware.
18:53:42 <roshi> +1 blocker, as is
18:53:55 <kparal> we're not voting, I think
18:54:05 <Viking-Ice> ?
18:54:16 <Viking-Ice> "do we still think it's a blocker?"
18:54:19 <roshi> well, just saying that it's still a blocker
18:54:22 <roshi> imo
18:54:27 <kparal> it still crashes
18:54:33 <Viking-Ice> hence still a blocker ;)
18:54:34 <kparal> crashed for me 30 minutes ago
18:54:39 <jreznik> and seems like it is
18:54:47 <Viking-Ice> kparal, that's ages ago
18:54:57 <kparal> #info there are still use cases when anaconda crashes, kparal will add more info soon
18:55:19 * kparal moving on
18:55:40 <adamw> oh huh, if it still crashes, sure does seem like a blocker, yeah.
18:55:41 * kparal skipping verified
18:55:50 <kparal> #topic (1036705) BootLoaderError: bootloader install failed when /boot on RAID 10(?)
18:55:50 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1036705
18:55:51 <kparal> #info Accepted Blocker, anaconda, NEW
18:56:33 <Viking-Ice> 19:00 my time to exit and meet and greet with the mc later...
18:56:45 <kparal> #info anaconda intends to disallow /boot on LVM, which should prevent this bug
18:56:52 <adamw> so this is the one which dlehman is proposing to 'fix' by disallowing /boot-on-LVM. at least that was the plan last I heard.
18:57:29 * nirik nods.
18:57:45 * kparal moving on
18:57:59 <kparal> #topic (1035531) Fedora 20 final release notes required for GA
18:57:59 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035531
18:57:59 <kparal> #info Accepted Blocker, fedora-release-notes, MODIFIED
18:58:25 <kparal> "<randomuser> pschindl, when the time comes, please note that a fix has been pushed, and that if something further is needed for some reason you can ping via bz or email me for a more immediate response"
18:58:51 <kparal> #info a new update is pushed, needs karma
18:59:01 <jreznik> yep, I talked randomuser earlier today
18:59:07 <jreznik> (to)
18:59:15 <jreznik> so built as planned
18:59:22 * kparal moving on
18:59:34 <kparal> #topic (1024223) fedup 19->20 failed with DVD iso upgrade
18:59:34 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1024223
18:59:34 <kparal> #info Accepted Blocker, fedup, MODIFIED
19:00:21 <kparal> #info a patch is pushed, wwoods should create a new build soon
19:00:52 <kparal> there seems to be a lot of stuff missing in fedup's initrd
19:01:03 <kparal> generic one would really help
19:01:41 * kparal moving on, if nobody wants to add further comments
19:02:08 <kparal> #topic (864198) grubby fatal error updating grub.cfg when /boot is btrfs (and anaconda allows the creation of such a layout in custom partitioning)
19:02:08 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=864198
19:02:08 <kparal> #info Accepted Blocker, grubby, ASSIGNED
19:02:36 <adamw> also being 'fixed' by not allowing it.
19:02:56 <kparal> #info also being prevented by disallowing /boot on btrfs
19:03:10 <ignatenkobrain> wow /boot on btrfs ? so... interesting :D
19:03:10 <kparal> #info patch ready, waiting for new build
19:03:29 * kparal moving on, if nobody wants to add further comments
19:03:41 <jreznik> move on
19:03:44 <kparal> #topic (1004621) plasma-nm doesn't attempt to connect to any listed networks on Fedora KDE live
19:03:44 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1004621
19:03:44 <kparal> #info Accepted Blocker, kde-plasma-nm, ON_QA
19:03:46 <cmurf> ignatenkobrain: it's a lot more robust than say XFS on LV on md raid6 which is also permitted
19:03:58 <cmurf> (for booting from)
19:04:07 <kparal> no development here it seems
19:04:39 <kparal> the update has -3 karma
19:04:53 <kparal> should we move back to assigned, probably?
19:05:11 <jreznik> kparal: that update is nonsense, the real change was switching to kdm
19:05:30 <jreznik> so it has to be verified now
19:05:34 <kparal> jreznik: is the change effective yet?
19:05:39 <kparal> in TC4?
19:06:11 <jreznik> I hope so
19:06:15 <roshi> yeah - the sddm to kdm switch was supposed to be TC4
19:06:22 <roshi> iirc from what adamw said
19:06:40 <kparal> #info the linked update is not related, TC4 should contain kdm instead of sddm, so that this can be tested
19:06:47 <kparal> roshi: please add that info into the bugzilla, thanks
19:06:58 <roshi> you got it :)
19:07:05 * kparal moving on, if nobody wants to add further comments
19:07:33 <kparal> #topic (1032921) KDE f20 TC2 x86_64 fails to shutdown from menu bar
19:07:33 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1032921
19:07:33 <kparal> #info Accepted Blocker, kde-workspace, NEW
19:08:07 <adamw> yeah, tc4 should have KDM
19:08:15 <adamw> sorry, i disappeared
19:08:26 <jreznik> this one is really very unpredictable and hard to reproduce reliably, it just happens... sometimes
19:08:45 <adamw> i'll try and find a minute to confirm the fix for 1004621 with TC4
19:08:55 <kparal> #info this needs testing with TC4, instructions are present in the bug
19:08:57 <adamw> state of the art is KDE is blaming the systemd slow startup bug
19:09:08 <adamw> which may be fixed in tc4 or may not. so that's not going to confuse anyone at all.
19:09:15 <jreznik> adamw: mbriza hit today but did not hit slow boot...
19:09:39 <jreznik> hit it - too tired :(
19:09:45 <kparal> #info this also might be influenced by system slow startup bug
19:09:52 <kparal> #undo
19:09:52 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x9313310>
19:09:56 <kparal> #info this also might be influenced by systemd slow startup bug
19:10:04 <jreznik> they are on it but it's really hard to find the root cause for this one... heisenbug
19:10:16 * kparal moving on, if nobody wants to add further comments
19:10:25 <adamw> yeah, i don't think we have much light to shed
19:10:41 <kparal> #topic (1035536) Final spin-kickstarts build required for Fedora 20 GA
19:10:41 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1035536
19:10:41 <kparal> #info Accepted Blocker, spin-kickstarts, ASSIGNED
19:10:46 <jreznik> I'm in touch with guys... will follow it up (for previous one)
19:11:30 <kparal> #info a new update is ready, needs karma
19:11:33 <nirik> related to spin kickstarts, I was going to bring up: https://bugzilla.redhat.com/show_bug.cgi?id=1023178
19:11:44 * nirik can wait for open floor tho, sorry
19:12:00 <kparal> nirik: I'll mention it after we're done with this section
19:12:10 <nirik> kparal: don't we need a new one now?
19:12:29 <kparal> a new one what?
19:12:38 <nirik> oh, he did submit on.
19:12:42 <nirik> one. nevermind, move on.
19:12:48 <kparal> ok
19:12:48 <nirik> spin-kickstarts package.
19:13:11 <kparal> #topic (1006386) Journal flushing often slow, can prevent system booting correctly
19:13:11 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1006386
19:13:11 <kparal> #info Accepted Blocker, systemd, MODIFIED
19:13:35 <adamw> nirik: there's an older report for that, i think.
19:13:44 <adamw> nirik: i spent a bit of time looking at it then got distracted by more important things.
19:15:05 <kparal> #info there is an update and some testing going on. more testers welcome
19:15:17 <kparal> does anybody know more details?
19:15:25 <adamw> newp.
19:15:39 <jreznik> well, I talked to Michal today and he's not sure what that backported patches do...
19:16:30 <kparal> so, waiting for a magic fix
19:16:31 <jreznik> so it needs more testers to help with
19:16:53 <kparal> pschindl was the only one to hit it from us
19:16:54 <jreznik> one workaround pschindl confirmed was limiting size of log file...
19:16:58 <kparal> it seems it works for him
19:17:18 <kparal> but the log is rotated every few days with this setup
19:17:27 <jreznik> it is...
19:17:40 <adamw> i'm not convinced by any of the 'confirmations of fixes' yet, tbh
19:17:50 <jreznik> yeah
19:17:58 <adamw> they all seem to come back and say, "er, but, maybe not"
19:18:04 <kparal> a bad choice of the release name, again
19:18:21 <jreznik> and tom london's logs are not very convincing
19:18:47 <kparal> let's finish this section off. the last one accepted blocker:
19:19:01 <kparal> #topic (1026860) Instantiated service is not run, it stays in inactive state (and systemd debug log does not state why)
19:19:01 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1026860
19:19:01 <kparal> #info Accepted Blocker, systemd, NEW
19:19:31 <kparal> still broken
19:19:50 <adamw> hey, at least now we have a clear statement about what needs fixin' :|
19:20:06 <kparal> #info this seems to be still broken and waiting for developers
19:20:39 <jreznik> peter needs more logs
19:20:58 <jreznik> he's trying to fix it, no workarounds available
19:21:07 <jreznik> but he thinks it's in systemd
19:21:29 <jreznik> systemd guys are trying to prepare a build with more debug info available for him
19:21:55 <adamw> good summary, thanks.
19:22:20 <kparal> #topic Open Floor
19:22:26 <kparal> let's start with nirik's bug
19:22:37 <nirik> sure.
19:22:40 <kparal> #topic 1023178 - RPM GPG key not imported on live images
19:22:44 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1023178
19:23:12 <kparal> so, this is related to spin-kickstarts
19:23:17 <kparal> we might need another build
19:23:35 <kparal> but at least we're now consistent with dvd behavior :P
19:23:35 <nirik> so, there's history here... we never used to import keys in the images.
19:23:49 <nirik> but not sure if we relented and started doing that.
19:24:48 <nirik> yeah, we have the import in the base ks file.
19:25:06 <nirik> # work around for poor key import UI in PackageKit
19:25:06 <nirik> rm -f /var/lib/rpm/__db*
19:25:06 <nirik> rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
19:25:08 <adamw> i thought we *did* used to do it in live images, but not in DVDs
19:25:11 <kparal> in previous releases Live installation had the keys trusted, DVD installs not
19:25:16 <adamw> like kparal says, it's 'famous' that this 'works' in live but not DVD
19:25:24 <nirik> see also 998. ;)
19:25:32 <adamw> right
19:26:04 * adamw goes to look at a live image creation log and see what happens with that command
19:26:19 <nirik> yeah.
19:26:44 <adamw> so, er, btw, subtext of this meeting is that we're really not expecting to ship this week, right? we're not going to look at making some dodgy blocker waivers.
19:27:05 <nirik> adamw: it seems unlikely since we don't even have an rc1. ;(
19:27:20 <adamw> well, i've been keeping the option of a 'hero' rc1 this morning open
19:27:26 <roshi> mad testing before tomorrow
19:27:27 <adamw> but it's kinda seeming like we're not going there
19:27:52 <roshi> if there was an RC
19:28:55 <adamw> roshi: that's kinda normal :P
19:29:02 <roshi> lol
19:29:34 <adamw> right now we could actually do an anaconda build and then plausibly claim everything but https://bugzilla.redhat.com/show_bug.cgi?id=1026860 is 'addressed'
19:29:40 <kparal> #topic Open Floor
19:30:15 <adamw> so...if we wanted some fudge we could try and deny that one blocker status. i'm just listing the possibility.
19:30:22 <nirik> well, I'm happy to help if we can make it... but...
19:30:39 <adamw> in practice, though, it seems highly likely either the systemd-slow-boot or kde bug would still be there.
19:30:48 <adamw> oh, wait, there's the fedup bug too. and we were strongly +1 on that.
19:30:53 <adamw> sorry, thinking out loud
19:30:59 <kparal> there's also 1027947
19:31:12 <kparal> dlehman just confirmed on #anaconda that he still hasn't fixed it yet
19:31:17 <adamw> right
19:31:24 <adamw> i was kinda figuring that got fixed in the anaconda build
19:31:28 <adamw> so yeah, signs point to slip
19:32:03 <kparal> one week doesn't matter, we can still release before Christmas
19:32:05 <nirik> error: /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora--: import read failed(2).
19:32:15 <kparal> but two weeks slip would go to January
19:32:22 <nirik> no releasever/basearch set in chroot likely
19:32:31 <nirik> kparal: yep.
19:32:36 <jreznik> kparal: yep, it would, one week is still possible
19:32:48 <adamw> ah, that's actually what i thought it was going to be!
19:32:49 <adamw> ten points to me
19:32:55 <nirik> thats why we asked for the week move up of final freeze. ;)
19:33:11 <adamw> you social engineers you
19:33:15 <nirik> adamw+10
19:33:28 * kparal is lost
19:34:01 <kparal> anyway, anything else to discuss?
19:34:55 <jreznik> all set, I'll continue to ping people...
19:35:15 * jreznik has to run now
19:35:21 <danofsatx> what about 1035799?
19:35:22 <kparal> jreznik: thanks, see you
19:35:26 <danofsatx> .bug 1035799
19:35:30 <zodbot> danofsatx: Bug 1035799 f20 tc3, adding a new mount point, desired capacity empty, crash - https://bugzilla.redhat.com/show_bug.cgi?id=1035799
19:35:36 <adamw> i think jreznik and i have our nervous breakdowns nicely scheduled
19:35:49 <adamw> danofsatx: it's fixed and the fix confirmed in TC4, i think?
19:35:57 <adamw> oh, GNOME folks are asking me about https://bugzilla.gnome.org/show_bug.cgi?id=709027 as an FE
19:36:01 <adamw> might be possible to take it if we slip
19:36:07 <kparal> danofsatx: the status says VERIFIED, I skip those bugs
19:36:25 <danofsatx> Oh, I missed the "verified" part. sorry 'bout that
19:36:30 * danofsatx is still learning
19:36:41 <kparal> #topic GNOME Bug 709027 - List mode has black background
19:36:48 <kparal> #link https://bugzilla.gnome.org/show_bug.cgi?id=709027
19:37:15 <adamw> obivously we'll file an rh bug for it if necessary
19:37:22 <adamw> but just thought i'd get it in before the meeting closes
19:37:27 <kparal> funny
19:37:31 <adamw> i guess i'd be a weak +1 with a slip, definite -1 with no slip
19:37:34 <kparal> +1 FE
19:37:39 * nirik is with adamw
19:38:05 <kparal> I wouldn't be so definite, but I agree
19:38:25 <adamw> ok, i guess i'll get an rh bug filed and ping for votes
19:38:31 <kparal> still interesting that I haven't seen this
19:38:40 <adamw> kparal: it apparently doesn't affect many apps
19:38:45 <adamw> possibly only gnome docs
19:38:58 <kparal> ah
19:39:08 <kparal> nobody uses that anyway, so no big deal :P
19:39:11 <roshi> I'm with adamw on the votes, weak or none
19:39:14 <roshi> lol
19:39:21 <roshi> dpending on slip
19:39:27 <adamw> kparal: that was kinda my thought but i didn't want to say it :P
19:39:37 <adamw> kparal: actually, it finds stuff in remote accounts now, which is kind of useful
19:39:38 * roshi just left an 'e' out of "depending" to be efficient
19:39:42 <kparal> oh, I'm very forward
19:39:45 <adamw> 'online accounts' - owncloud etc
19:39:54 <adamw> roshi: very fficint
19:39:58 <adamw> SEE WHAT I DID THERE
19:40:06 <roshi> idid
19:40:16 <roshi> 1337speak for a new generation
19:40:29 <roshi> or, was that us from before?
19:40:54 <kparal> lts skp ll th vwls, jst fr fn
19:41:06 <roshi> snds gd t m
19:41:10 <adamw> h wr gng ll prml scrm
19:41:24 * kparal brain is melting
19:41:26 <roshi> grgl
19:41:34 <adamw> https://en.wikipedia.org/wiki/XTRMNTR
19:41:43 * roshi is done
19:41:44 <roshi> lol
19:42:03 <kparal> #topic Open Floor
19:42:07 <kparal> ok, anything else?
19:42:18 <adamw> i don't think so
19:42:27 <adamw> thanks for sticking around, kparal
19:42:29 <kparal> thanks everybody for coming
19:42:40 <kparal> #endmeeting