16:02:30 <tflink> #startmeeting f19final-blocker-review-1.1 16:02:30 <zodbot> Meeting started Thu May 30 16:02:30 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:30 <tflink> #meetingname f19final-blocker-review-1.1 16:02:30 <tflink> #topic Roll Call 16:02:30 <zodbot> The meeting name has been set to 'f19final-blocker-review-1.1' 16:02:52 <tflink> Time for a continuation of the blocker review from yesterday 16:03:07 * satellit listening 16:03:51 <kparal> we finished the blockers yesterday, and today there are 11 blockers. yeehaw! 16:06:05 <kparal> tflink: can we prioritize blockers that I or vbocek are involved in? I need to leave in ~90 minutes 16:07:06 <tflink> kparal: do you have the bugids handy? 16:07:28 * kparal gathering 16:08:18 <tflink> wow, a lot of those proposed blockers are new since yesterday 16:09:02 <kparal> tflink: 965865 967527 968915 968951 919855 968936 968794 16:09:04 * tflink enjoys the blocker review process _so_ much 16:09:55 * kparal is to blame for a lot of them 16:10:26 <kparal> we couldn't help but to spot soooo maaany problems... 16:10:51 * tflink is reminded of a bug reduction technique called "sending the testers to the movies" 16:11:06 <kparal> ah, I like that one. or on vacation, even better 16:15:25 <tflink> sorry, I keep getting distracted 16:15:34 <tflink> not sure we have enough people to do the review anyways 16:15:38 <tflink> adamw: around? 16:15:49 <tflink> jreznik said he couldn't make 16:15:54 <tflink> make it today 16:16:48 <adamw> yo 16:16:55 <adamw> oh boy i totally forgot we were doing this again 16:17:14 * adamw sends kparal on vacation to siberia 16:17:31 <kparal> to a forced-labor camp, I know :) 16:17:48 <kparal> you just with is wasn't Fedora-bug-testing-forced-labor camp! 16:17:52 <kparal> *wish 16:18:43 <adamw> it's a special camp where you file useless bug reports against ubuntu all day long 16:18:50 <kparal> :D 16:19:13 <kparal> actually, they wouldn't notice. they haven't noticed even my useful reports 16:19:39 <kparal> maybe if it were against unity or mir or something similarly cool 16:20:50 <tflink> I suppose we have enough to at least try to get started 16:21:04 <tflink> enough to bore people with boilerplate, anyways :) 16:21:13 <tflink> #topic Introduction 16:21:20 <tflink> Why are we here? 16:21:20 <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:21:28 <tflink> #info We'll be following the process outlined at: 16:21:28 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:21:34 <tflink> #info The bugs up for review today are available at: 16:21:34 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current 16:21:41 <tflink> #info The criteria for release blocking bugs can be found at: 16:21:41 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria 16:21:44 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria 16:21:47 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria 16:21:50 <tflink> #info Up for review today, we have: 16:21:57 <tflink> #info 11 Proposed Blockers 16:21:57 <tflink> #info 4 Accepted Blockers 16:21:57 <tflink> #info 11 Proposed Freeze Exceptions 16:21:57 <tflink> #info 7 Accepted Freeze Exceptions 16:22:35 <tflink> kparal requested that we start with the bugs that he's involved with as he needs to leave before too long 16:22:53 <tflink> I suspect we're not going to get through the whole list, though 16:23:07 <tflink> #topic (965865) ValueError: ('invalid size specification', '-880.000000 MB') 16:23:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=965865 16:23:13 <tflink> #info Proposed Blocker, anaconda, NEW 16:23:51 <kparal> you can read comment 18, I asked vbocek to try to duplicate mark's layout (some of the raid partitions missing) 16:23:58 <kparal> we were unable to reproduce the crash 16:24:00 <adamw> still no success 16:24:10 <adamw> i think we can keep the punt decision for now, but probably leaning -1 without further data 16:24:29 <tflink> isn't the bug about lvm on md raid5? 16:24:58 <tflink> not standard partitions 16:25:54 <kparal> it seems that hi bypassed this bug when he used empty disks and run to another one instead 16:25:56 <adamw> i think i lost track of all the details in there 16:26:36 <kparal> +1 for punt, I just wanted to mention that we couldn't reproduce 16:26:47 <kparal> no need to vote I think 16:27:02 <tflink> ok, not sure your attempted reproduction was accurate 16:27:25 <kparal> not fully accurate of course, I just asked Vojtech to use an existing incomplete raid array 16:27:30 <kparal> over 3 disks 16:27:44 <kparal> similarly to what I saw in the video 16:27:45 <tflink> in order for hamzy to have hit 966795, he has to be using lvm which could be part of this problem 16:28:16 <tflink> ie, another facet of problems with lvm-on-mdraid 16:29:23 <tflink> proposed #agreed 965865 - The cause of this is still very unclear, will revisit at a later meeting 16:29:37 <kparal> ack 16:29:53 <adamw> ack 16:30:09 <tflink> #agreed 965865 - The cause of this is still very unclear, will revisit at a later meeting 16:30:44 <tflink> #topic (967527) /root/anaconda-ks.cfg crashes anaconda 16:30:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=967527 16:30:44 <tflink> #info Proposed Blocker, anaconda, NEW 16:31:15 <kparal> Vojtech added the requested information 16:31:44 <tflink> this sounds like a fun one 16:31:51 <kparal> according to his testing, it actually fails to install in 7 out of 8 attempts with clearpart --none and an empty disk 16:32:11 <kparal> i.e. fails to set up partitioning correctly 16:32:13 <tflink> and 3 out of 4 with clearpart --all 16:32:22 <kparal> right 16:32:48 <kparal> maybe we should separate that into a new bug 16:32:49 <adamw> yeah...it seems like the crash is kinda uncommon but it's still not installing 16:32:56 <adamw> oh, didn't we have another bug like that? 16:33:06 <adamw> the one where there was kind of a philosophical disagreement going on? 16:33:17 <kparal> that was about the network 16:33:23 <kparal> not about partitioning 16:33:33 <adamw> ah. 16:34:06 <adamw> oh, he has 'autopart' above 'clearpart' in the ks 16:34:08 <tflink> blocker thoughts? 16:34:13 <kparal> there can be something wrong with the kickstart that's causing this. but it was taking from a default installation 16:34:16 <kparal> *taken 16:34:17 <adamw> when i play with ks'es i seem to find ordering is important 16:34:26 <adamw> be interesting to know what happens with clearpart above autopart... 16:34:48 <kparal> we can re-test 16:34:58 <kparal> still I think this seems +1 blocker 16:35:21 <tflink> I'm not -1 16:35:39 <tflink> adamw's point about ordering seems significant, though 16:35:51 <kparal> what does documentation say? 16:35:53 * kparal looks 16:36:25 <adamw> i'm not -1 either 16:36:29 <adamw> just trying to nail down details 16:36:36 * adamw is trying with the ks from the bug 16:36:55 <kparal> I don't see any instructions for commands order in the documentation 16:37:25 <kparal> but if there's nothing wrong with this particular kickstart, this bug would render automated installation useless 16:37:27 <adamw> huh. i get 'error setting up software source' when i run that ks against the dvd... 16:37:45 <adamw> and the dvd itself isn't available as a choice on the installation source spoke... 16:37:45 <kparal> adamw: that's the network bug I guess :) add "cdrom" 16:38:19 <adamw> first time i tried it the storage config worked, though 16:38:58 <kparal> since it's a race condition, you can have completely different results 16:39:26 <adamw> yeah. 16:39:48 <adamw> 3 successful tries 16:40:31 <adamw> 4 16:41:22 <adamw> 5. seems to work reliably for me... 16:41:23 <tflink> adamw: with the reordering? 16:41:27 <adamw> no 16:41:38 <adamw> same order as attached to the bug, but i changed clearpart --none to clearpart --all and added cdrom 16:41:57 <kparal> it just crashed for me :) 16:42:41 <adamw> i think we agreed that there's a crash if you run it with clearpart --none and a full disk but thought that wasn't terribly important 16:43:08 <kparal> ok, I changed to clearpart --all 16:43:11 <kparal> and added cdrom 16:43:26 <kparal> and on 1st attempt I get "No disks selected" 16:43:45 <adamw> it would probably help to have both fail and success logs 16:44:17 <adamw> i can't get it to crash even with clearpart --none :/ 16:44:22 <adamw> seems i don't have the magic bug thumbs 16:44:54 <adamw> so i guess this might depend on how common it's likely to be 16:45:18 <adamw> maybe punt again, ask for vojtech or kparal to attach logs from all failure and success cases, and wait for dev input 16:45:19 <adamw> ? 16:45:49 <kparal> second attempt the same 16:45:51 <kparal> ok 16:47:06 <kparal> I don't know, three times the same 16:47:17 <tflink> proposed #agreed 967527 - non-reporters are having difficulty reproducing this bug, revisit after dev input on pass/fail logs 16:47:19 <adamw> seems like only vojtech gets the unpredictable result :) 16:47:21 <kparal> adamw: should we split the report? 16:47:29 <adamw> tflink: kparal isn't having any trouble reproducing it, i don't think... 16:47:43 <adamw> kparal: sure, the crash is a valid bug on its own, be clearer to separate out the two cases 16:47:48 <kparal> alright 16:47:49 <adamw> tflink: he's having trouble *not* reproducing it 16:47:51 <kparal> will do 16:47:53 <tflink> the bug is getting dumped to the hub with no disks selected, right? 16:48:07 <kparal> tflink: right 16:48:13 <tflink> I just repro'd 16:48:17 <adamw> tflink: there's two bugs, the initial crash with clearpart --none, and then not getting the partitioning setup with clearpart --all 16:48:23 * adamw is feeling left out now 16:48:41 <adamw> so you guys just took the ks attached to the bug, added 'cdrom' at the top, and changed 'clearpart --none blah' to 'clearpart --all blah'? 16:48:42 <kparal> adamw: bad karma 16:48:52 <kparal> adamw: right 16:48:55 <adamw> actually can you guys just use mine and confirm you still hit the bug? 16:48:56 * tflink used the ks verbatim 16:49:03 <adamw> http://www.happyassassin.net/ks/967527.ks 16:49:48 * kparal running it 16:50:24 <tflink> no disks selected 16:50:43 <kparal> adamw: crashed, because it has clearpart --none 16:51:00 <adamw> oh yeah, i changed it to --none 16:51:06 <adamw> to see if i could make the crash happen 16:51:15 <adamw> changed to all 16:51:18 <kparal> I have 2 cpus in the VM, btw 16:51:32 * tflink tries again 16:52:23 <kparal> no disks selected 16:52:30 <adamw> huh. 16:52:47 <tflink> install started 16:52:49 <adamw> for me that one goes straight to installation 16:52:56 <tflink> same here 16:53:52 <adamw> welp, anyway, kparal can split the bugs up and we can look at 'em again next time, i guess if two people get what's clearly an incorrect result the majority of the time that's definitely bad 16:54:15 <tflink> I wonder what's different in the environments 16:54:20 <kparal> it's just racy 16:54:45 <kparal> let's move on 16:55:29 <kparal> time is short, or whatever the correct phrase is :) 16:55:32 <adamw> yes 16:55:35 <tflink> proposed #agreed 967527 - some people can reproduce the behavior, others are not able to. will split this bug into two for the different issues and will revisit after dev input 16:55:47 <kparal> ack 16:56:31 <adamw> ack 16:56:36 <tflink> #agreed 967527 - some people can reproduce the behavior, others are not able to. will split this bug into two for the different issues and will revisit after dev input 16:56:50 <tflink> #topic (968915) Anaconda locks user account instead of creating it password-less 16:56:53 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968915 16:56:56 <tflink> #info Proposed Blocker, anaconda, NEW 16:57:15 <adamw> +1, this could leave you pretty screwed in KDE path 16:57:17 <kparal> this is a very recent regression. I used password-less user accounts in Beta RC something 16:57:21 <adamw> (g-i-s saves the GNOME path, but it still looks bad) 16:57:43 * adamw tests to see if he can repro 16:57:47 <kparal> I believe the cause is related to the CVE bug 16:58:00 <adamw> i don't see how, but i guess it's possible 16:58:16 <kparal> well there were some changed related to password locking, wasn't it? 16:58:22 <adamw> yes, but in livecd-tools 16:58:28 <kparal> hm 16:58:31 <adamw> and it was only to do with how the root account was set 16:58:50 <kparal> ok 16:58:58 <tflink> +1 16:59:31 <kparal> +1 blocker 16:59:42 <adamw> (assuming it's reproducible) 16:59:46 <kparal> it is 16:59:56 <kparal> no race here 17:00:07 <kparal> several attempts, different computers, two people 17:00:33 <tflink> proposed #agreed 968915 - AcceptedBlocker - Violates the following F19 alpha release criterion for installs with a passwordless user created during install: "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot." 17:00:50 <kparal> ack 17:01:00 <adamw> ack 17:01:06 <tflink> #agreed 968915 - AcceptedBlocker - Violates the following F19 alpha release criterion for installs with a passwordless user created during install: "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot." 17:01:13 <kparal> btw, maybe we can invite someone from #anaconda? 17:01:21 <tflink> #topic (968951) User data from first boot are copied to new users 17:01:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968951 17:01:21 <tflink> #info Proposed Blocker, gnome-initial-setup, NEW 17:02:15 <adamw> kparal: i can ask... 17:02:20 <adamw> well, once we get back to anaconda bugs 17:02:39 <kparal> g-i-s should be executed for every new user. but on the first boot, it instead copies the settings of the first user to all other newly created users 17:02:53 <kparal> instead of running again, it just takes the existing data and skips the dialogs 17:03:01 <tflink> fun 17:03:02 <kparal> after first reboot, everything works fine 17:03:27 <kparal> we don't know whether it copies also passwords(keyring), because there is a bug that the passwords are not saved :) 17:03:43 <kparal> but it definitely copies all online accounts definitions - user names, server settings, etc 17:04:30 <kparal> so, this can be quite a privacy issue 17:04:33 <adamw> i suppose we could count this as a security issue 17:04:44 <adamw> refer it to sec team for a rating? 17:05:25 <kparal> I don't know how to proceed with security bugs 17:05:50 <tflink> yeah, not sure if it hits any criteria otherwise 17:06:15 <tflink> does it happen if you create multiple users between reboots or just before the first reboot? 17:06:39 <kparal> it all happens after the first system start, before you reboot 17:06:41 * satellit can you create more than one in either anaconda or g-i-g/ 17:07:06 <satellit> g-i-s8 17:07:08 <adamw> satellit: that's not the reproducer 17:07:21 <adamw> satellit: g-i-s creates one, admin, user account and immediately logs you into it 17:07:23 <kparal> so you install, reboot, boot for the first time, create first user, !!create more users!!, reboot, now it's fine 17:07:40 <adamw> if you then create more user accounts from that admin user account without rebooting, they have the settings from the admin account applied to them 17:07:44 <kparal> in !!area!! the bug occurs 17:07:52 <satellit> ouch 17:07:59 <kparal> adamw: right 17:08:01 <satellit> or .ks/ 17:08:41 <adamw> the definition of 'important impact' for an rh security issue is "This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources." 17:08:44 <adamw> that seems to fit the bill here 17:08:45 <kparal> there are also some secondary side-effects, like the welcome video playing every time for every login for every user, until you reboot :) 17:08:54 <adamw> so i'd actually be fine calling this a blocker under the security criterion 17:09:06 <tflink> no objections here 17:09:10 <kparal> +1 17:09:16 <satellit> or if you install a 2nd DE - i-s is triggerd for it 17:09:36 <kparal> satellit: this is affecting just gnome-initial-setup 17:09:40 <adamw> satellit: this wouldn't affect anything outside of GNOME. 17:09:41 <satellit> ok 17:10:56 <tflink> proposed #agreed 968951 - AcceptedBlocker - Violates the following F19 final release criterion when creating a second user right after running gnome-initial-setup for an admin user: "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)" 17:11:11 <adamw> ack 17:11:14 <kparal> ack 17:11:59 <tflink> #agreed 968951 - AcceptedBlocker - Violates the following F19 final release criterion when creating a second user right after running gnome-initial-setup for an admin user: "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)" 17:12:17 <tflink> #topic (919855) [abrt] gnome-settings-daemon-3.7.91-1.fc19: getenv: Process /usr/libexec/gnome-settings-daemon was killed by signal 11 (SIGSEGV) 17:12:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=919855 17:12:22 <tflink> #info Proposed Blocker, gnome-settings-daemon, NEW 17:12:25 <kparal> a race condition! 17:12:29 <kparal> rejoice 17:12:36 <adamw> golly gee. 17:12:43 <kparal> in 1 in many (~10) boots, the gdm doesn't start 17:12:47 <kparal> just a black screen 17:12:55 <kparal> gnome-settings-daemon crashes 17:13:11 <adamw> i've never seen this one, fwiw 17:13:13 <kparal> I've seen in on multiple computers for multiple people 17:13:15 <adamw> but it sounds bad 17:13:47 <tflink> are enough people hitting it often enough to justify blocking release? 17:14:15 <kparal> well I saw occasional black screen for me, Josef, Vojtech and Ben. but I can't say it was always this bug 17:14:28 <kparal> for me and Josef it surely was 17:14:59 <kparal> I tried rebooting my VM and hit it twice in 10 boots 17:15:04 <adamw> #0 __GI_getenv (name=0x38d7b7a989 "NGUAGE", name@entry=0x38d7b7a987 "LANGUAGE") at getenv.c:89 17:15:05 <adamw> 89 getenv.c: No such file or directory. 17:15:10 <adamw> could be related to l10n? 17:15:26 <kparal> hmm, those were default language installations, IIRC 17:15:32 <kparal> i.e. en_US 17:15:35 <adamw> hum 17:15:58 * adamw asks hadess 17:16:17 <adamw> if i had to make a call right now i guess i'd lean +1, but... 17:18:54 <tflink> all in vms? 17:19:08 <kparal> no, VM and bare metal 17:19:17 <adamw> kparal: do you have a clean backtrace? 17:19:23 <adamw> <hadess> #0 __GI_getenv (name=0x38d7b7a989 "NGUAGE", name@entry=0x38d7b7a987 "LANGUAGE") at getenv.c:89 17:19:24 <adamw> <hadess> adamw, it's memory corruption, the backtrace is unusable 17:19:24 <adamw> adamw, and if it isn't, it's crashing in gettext 17:19:43 <kparal> adamw: you mean a fresh one? it should be stored somewhere in my VM, I can retrieve it 17:19:49 <adamw> yeah 17:20:16 <adamw> we really need a 'send a new bt' button for abrt :( 17:20:53 <kparal> abrt developers are great to talk with, lately. just file a RFE please 17:20:54 <adamw> ok, i guess i'm tentative +1 or punt for developer input 17:21:02 <adamw> yeah, i have it on my epic todo list 17:21:06 <kparal> I need to leave soon, but I'll provide the backtrace 17:21:10 <adamw> thanks 17:21:17 <kparal> once I'm back 17:21:45 <kparal> I'm +1 blocker. I saw it way too often 17:22:05 <kparal> but we can punt 17:22:10 <kparal> I don't mind 17:22:24 <adamw> tflink, vote? 17:22:26 <tflink> I'd rather punt - this isn't a clear criteria violation and there are only 3 of us 17:22:38 <tflink> I'm definitely not -1 17:23:02 <kparal> punt it is, then 17:23:43 <kparal> one more bug, let's go :) 17:24:02 <adamw> yup 17:24:36 * kparal suggests 968936 17:24:54 <tflink> proposed #agreed 919855 - While this seems like it has blocker potential, it isn't a clear criteria violation and it would be better to have more than 3 people voting to take it as a blocker. Will revisit at the next review meeting 17:25:08 <kparal> ack 17:25:09 <tflink> kparal: that was next on my list anyways 17:25:29 <kparal> tflink: I know, just giving adamw a head start :) 17:25:43 <adamw> ack 17:25:52 <tflink> #agreed 919855 - While this seems like it has blocker potential, it isn't a clear criteria violation and it would be better to have more than 3 people voting to take it as a blocker. Will revisit at the next review meeting 17:26:07 <tflink> #topic (968936) SIGSEGV of packagekit-offline-update.service during update 17:26:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968936 17:26:12 <tflink> #info Proposed Blocker, PackageKit, NEW 17:26:37 <kparal> it seems that online updates work, but offline updates are totally dead 17:26:50 <kparal> but it might be influenced by the repo contents, I don't know 17:26:53 * ignatenkobrain here 17:27:12 <adamw> is this from DVD or live install? 17:27:31 <kparal> both say DVD 17:28:29 <adamw> i'm nurturing a theory that it doesn't work until you import the fedora gpg key 17:28:36 <adamw> so it works from live because that's done in the live kickstarts 17:28:48 <adamw> and it'll work as soon as you've done any PK or yum transaction interactively 17:28:51 <kparal> ah, nice idea 17:29:13 <adamw> i didn't get around to confirming it yet :) 17:29:19 * adamw runs a dvd install 17:29:23 <kparal> we can confirm tomorrow 17:29:49 <tflink> I was wondering if it was another gpg key import before it works bug 17:30:17 <kparal> as adamw mentioned 17:30:38 <kparal> anyway, I need to leave 17:30:45 <kparal> I'll be back in 45 minutes or so 17:30:47 <tflink> so punt? 17:31:23 <adamw> well, let's see 17:31:27 <kparal> we can punt, but I think this is quite a problem 17:31:31 <adamw> if the bug *is* what i suspect it is, do we consider that a blocker? 17:31:42 <kparal> yes 17:31:47 <tflink> what have we done with the gpg import bugs in the past? 17:32:03 <kparal> it just worked, one more dialog you needed to confirm 17:32:16 <kparal> if PK failed to asked and failed to update, it was a blocker 17:32:18 <kparal> in the past 17:32:25 <adamw> right, i think the problem here is that the offline update code just doesn't have a provision to prompt you to import the key 17:32:50 <adamw> the thing is, you can still do online updates in gnome, in fact the 'updates available' notifications trigger the online update path 17:32:54 * kparal leaving, sorry. I'll be back! 17:32:58 <adamw> so really, both online and offline updates are available, it's kind of a mess 17:33:04 <tflink> kparal: I assume you're +1? 17:33:05 <adamw> so if only one of them is only partly broken, what do we do? 17:33:09 <kparal> tflink: yes 17:33:21 <adamw> i've had a bug in against GNOME on this forever, but it's still not cleaned up :( 17:33:38 <tflink> adamw: the offline updates or gpg key importing 17:33:55 <ignatenkobrain> +1 ащк ьу 17:34:02 <ignatenkobrain> +1 for me. sorry 17:34:03 <adamw> tflink: the fact that gnome doesn't have a clear update story any more 17:34:38 <tflink> I imagine that if push came to shove and online updates worked OOTB, this would get un-blocker-ified 17:36:02 <adamw> yeah that was kinda my worry too 17:36:05 <adamw> i can see it getting fudged 17:36:10 <tflink> would we use " 17:36:15 <tflink> The installed system must be able to download and install updates with yum and with the default graphical package manager in all release-blocking desktops."? 17:36:27 <adamw> yeah, again, something that kinda needs to be updated 17:36:30 <tflink> if so, that hits on your question about a clear update story 17:36:34 <tflink> which is the defaul? 17:36:37 <adamw> right 17:36:40 <tflink> and is it graphical 17:36:53 <adamw> well, that's just a case where we didn't envisage anything like this happening 17:37:01 <adamw> we kinda really mean 'each release-blocking desktop's default update method' 17:37:37 <tflink> yeah, more "the mechanism that isn't yum on the cli" 17:39:01 <tflink> we could take it to force the discussion if it's still open @ release time 17:39:10 <tflink> I guess I'm +1 17:39:32 <tflink> not just to force discussion, but that would be one reason not to shy away from it, I think 17:39:33 <adamw> yeah, i'm okay with that 17:39:46 <adamw> provisional +1 17:40:21 * adamw 's DVD install is just finishing u[ 17:40:33 <tflink> proposed #agreed 968936 - AcceptedBlocker - Violates the following F19 alpha release criteria for gnome's offline updates: "The installed system must be able to download and install updates with yum and with the default graphical package manager in all release-blocking desktops" 17:40:43 * tflink assumes ack from kparal 17:41:06 <ignatenkobrain> ack 17:41:28 <adamw> ack 17:41:46 <tflink> #agreed 968936 - AcceptedBlocker - Violates the following F19 alpha release criteria for gnome's offline updates: "The installed system must be able to download and install updates with yum and with the default graphical package manager in all release-blocking desktops" 17:41:55 <tflink> #topic (968794) KDE keyboard input impossible with ibus enabled and qt updated to 4.8.4-18 17:41:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968794 17:42:01 <tflink> #info Proposed Blocker, qt, NEW 17:42:07 <tflink> +1 17:43:05 <ignatenkobrain> +1 17:43:06 <tflink> not sure it clearly hits a criterion, though 17:43:18 <tflink> this is close "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use" 17:43:29 <tflink> but technically, this has nothing to do with translations 17:43:40 <tflink> although it does violate the spirit of that criterion 17:44:09 <ignatenkobrain> tflink: good idea 17:44:24 <adamw> i'd just say the 'working desktop' criterion for anyone who relies on ibus 17:44:34 <adamw> brb call of nature 17:45:06 <tflink> adamw: ah, that works 17:45:18 <jreznik> sorry for being late 17:45:22 <jreznik> very late 17:47:05 <ignatenkobrain> what end result ? 17:47:36 <tflink> proposed #agreed 968794 - AcceptedBlocker - Violates the following F19 final criterion for users who rely on ibus input on KDE: " All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use" 17:47:40 <ignatenkobrain> ack 17:48:03 <tflink> jreznik: we still have an hour left before hitting the time limit :) 17:48:31 <adamw> back 17:48:39 <adamw> ack 17:48:49 <ignatenkobrain> adamw: :) 17:50:04 <tflink> #agreed 968794 - AcceptedBlocker - Violates the following F19 final criterion for users who rely on ibus input on KDE: " All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use" 17:50:42 <tflink> #topic (968794) KDE keyboard input impossible with ibus enabled and qt updated to 4.8.4-18 17:50:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968794 17:50:48 <tflink> #info Proposed Blocker, qt, NEW 17:50:52 <tflink> whoops 17:50:55 <tflink> #undo 17:50:55 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x353c64d0> 17:50:57 <adamw> epic fial 17:50:58 <tflink> #undo 17:50:58 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x25f046d0> 17:51:01 <tflink> #undo 17:51:01 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x353c6e90> 17:51:03 <ignatenkobrain> epic 17:51:08 <tflink> adamw: you want to see epic fail? 17:51:22 <tflink> I could paste this whole list in :) 17:51:22 <ignatenkobrain> tflink: yep 17:51:35 <tflink> and spend the next hour undo-ing 17:52:34 <tflink> my desire for readable meeting logs is winning out over the desire to display epic fail :-/ 17:52:41 <adamw> aww 17:53:12 <tflink> #topic (969032) IOError: [Errno 9] Bad file descriptor 17:53:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=969032 17:53:12 <tflink> #info Proposed Blocker, anaconda, NEW 17:53:34 <ignatenkobrain> +1 from me. 17:54:29 <tflink> what locale is being used? 17:55:26 <ignatenkobrain> tflink: before choosing locale anaconda had crash. 17:56:32 <adamw> this seems...odd 17:56:44 <tflink> livecd? 17:57:17 <ignatenkobrain> tflink: netinst. if need I can try to boot from livecd 17:57:17 <tflink> or is rd.live.check the way that mediacheck is run 17:57:27 <ignatenkobrain> tflink: see comment 17:57:35 <adamw> ignatenkobrain: did you run the media check? 17:57:50 <ignatenkobrain> tflink: start DISPLAY=:1 anaconda works and installed 17:57:53 <ignatenkobrain> adamw: yep 18:01:40 <adamw> punt for data from python-babel maintainer? 18:02:17 <tflink> ignatenkobrain: if you hit this as well, can you add a comment to the bug? 18:03:00 <tflink> I thought you had just proposed it at first 18:03:27 <ignatenkobrain> tflink: my best friend has this bug. 18:04:08 <tflink> ok, so just one report so far? 18:04:43 <ignatenkobrain> tflink: possibly 18:05:07 <ignatenkobrain> huh! bug is changed 18:05:51 <ignatenkobrain> Component: anaconda → babel 18:06:02 * tflink votes punt to get more data 18:06:20 <tflink> if only one person is hitting this, I wonder if it's a bad usb key or something 18:06:21 <adamw> ignatenkobrain: yes, bcl just did that, because a lot of the backtrace is in python-babel 18:07:26 <tflink> other thoughts? 18:09:21 * adamw still says punt 18:09:24 <ignatenkobrain> maybe deffer to next review ? 18:10:23 <tflink> proposed #agreed 969032 - There isn't much data to go off of here. Ask reporter to try with a different usb stick and will revisit at a later review meeting. 18:10:35 <ignatenkobrain> ack 18:10:36 <adamw> ack 18:10:42 <tflink> #agreed 969032 - There isn't much data to go off of here. Ask reporter to try with a different usb stick and will revisit at a later review meeting. 18:11:38 <tflink> any objections to skipping proposed blockers which have no movement since we discussed them yesterday? 18:12:11 * kparal is back 18:12:31 <adamw> fine by me 18:14:16 <tflink> ok, moving on to the proposed FE 18:14:23 <ignatenkobrain> good 18:14:24 <tflink> #topic (965841) anaconda no longer creates /etc/sysconfig/network, systems without NetworkManager do not bring up network 18:14:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=965841 18:14:29 <tflink> #info Proposed Freeze Exceptions, anaconda, POST 18:14:44 <adamw> an obvious +1 fe for me, borderline blocker in fact 18:14:51 <adamw> we had lots of fun with this a few releases back iirc 18:15:08 <ignatenkobrain> -1/+1 18:15:41 <tflink> +1 18:15:44 <kparal> +1 fe 18:15:50 <adamw> the blocker case is remote minimal installs where you can't reach them after install 18:16:10 <kparal> minimal install contain NM now, don't they? 18:16:38 <tflink> proposed #agreed 965841 - AcceptedFreezeException - While not quite a blocker, this could be a big problem for systems which don't have NetworkManager installed. A tested fix would be considered past freeze. 18:16:59 <ignatenkobrain> ack 18:17:24 <adamw> kparal: does it? I forget 18:17:27 <adamw> but anyhoo, ack 18:17:38 <kparal> adamw: you changed it in comps some releases back 18:17:47 <adamw> i do stuff 18:17:49 <kparal> ack 18:18:02 <kparal> it was quite debated 18:18:05 <adamw> yeah, minimal has NM. but you can take it out easily enough. so FE is appropriate 18:18:29 <tflink> #agreed 965841 - AcceptedFreezeException - While not quite a blocker, this could be a big problem for systems which don't have NetworkManager installed. A tested fix would be considered past freeze. 18:18:37 <tflink> #topic (967660) anaconda erases additional biosboot partitions outside of what was setup for 'reformat' (destroys spare biosboot partitions one might have on other disks) 18:18:41 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=967660 18:18:43 <tflink> #info Proposed Freeze Exceptions, anaconda, NEW 18:19:22 <kparal> remind me, biosboot is used for GPT or UEFI? 18:19:58 <tflink> non-uefi systems 18:20:08 <kparal> so GPT, alright 18:20:25 <tflink> are they all gpt now? 18:20:35 <tflink> I thought we stopped forcing that for the non-uefi case 18:20:41 <adamw> yes we did 18:20:57 <adamw> but if you already have a GPT disk label and don't select to destroy all partitions on that disk, you'll still have one 18:21:10 <adamw> and you can pass a kernel parameter to use gpt, iirc, and it'll still be used if you have a >2TB disk 18:21:22 <adamw> so yes, gpt-on-bios still exists, it's just not as prominent 18:21:30 <kparal> isn't this a full-fledged blocker? the installer must not erase something not marked to erase 18:21:42 <adamw> it doesn't quiiiiite hit any of the partitioning criteria (reartes looked at that) 18:22:03 <adamw> you could argue it for "All known bugs that can cause corruption of user data must be fixed or documented at Common F19 bugs" final criterion 18:22:04 <kparal> it's the obvious kparal's criterion "don't destroy user data" 18:22:15 <adamw> i wouldn't object to that 18:22:44 <adamw> whether it's 'user data' seems arguable, but it kinda fits the intent: we broke their existing stuffs 18:23:18 <kparal> not to mention the other biosboot partition doesn't have to be spare. he could have used it for booting a different system from a different hdd, right? 18:23:35 <kparal> one biosboot on sda, boot fedora, one biosboot on sdb, boot debian 18:23:36 <adamw> indeed 18:23:47 <kparal> currently anaconda would erase both 18:23:47 <adamw> in fact it seems like that was his initial case - we nerfed his f17 install 18:23:50 <tflink> proposed #agreed 967660 - AcceptedBlocker - Violates the following F19 final release criterion for systems with multiple gpt biosboot partitions: "All known bugs that can cause corruption of user data must be fixed or documented at Common F19 bugs" 18:23:53 <adamw> ack 18:24:01 <kparal> ack 18:24:32 <tflink> #agreed 967660 - AcceptedBlocker - Violates the following F19 final release criterion for systems with multiple gpt biosboot partitions: "All known bugs that can cause corruption of user data must be fixed or documented at Common F19 bugs" 18:24:47 <tflink> #topic (966784) anaconda storage spoke is left in 'warning checking storage configuration' with the 'begin install' button unlocked (logs shows that the spoke is ready) 18:24:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=966784 18:24:53 <tflink> #info Proposed Freeze Exceptions, anaconda, NEW 18:25:18 <tflink> ha, I skipped one 18:25:25 <tflink> will go back when this one is done 18:26:28 <adamw> this seems weird 18:26:32 <adamw> i haven't seen this at all 18:26:36 <kparal> interesting, I never saw this one. but I usually delete partitions, not reformat 18:26:46 <kparal> that implies custom part 18:26:56 <tflink> well, is it a warning that wouldn't otherwise block installation? 18:26:57 <adamw> oh 18:27:00 <adamw> i think notabug 18:27:02 <adamw> 21:15:27,607 WARN anaconda: You have not specified a swap partition. Although not strictly required in all cases, it will significantly improve performance for most installations. 18:27:14 <tflink> yeah, notabug 18:27:16 <kparal> here we go 18:27:20 <adamw> it is just warning the user about that. it does it in a slightly weird way - you have to go into the spoke to read the warning - but that's teh design 18:27:30 <kparal> we can have +1 FE to improve the warning 18:27:34 <adamw> (i filed a bug arguing that the error should be available from the hub, but lost that argument) 18:28:34 <kparal> -1, unless anaconda teams wants to improve the dialogs, they can then re-propose 18:28:42 <kparal> sounds good? 18:29:19 <adamw> ack 18:29:42 <tflink> proposed #agreed 966784 - RejectedFreezeException - This may not be clear to users, but it is by design. If anaconda devs want to change the dialog, please re-propose. 18:29:51 <adamw> ack 18:29:52 * satellit_e for install to USB you do not want swap with ext4 18:30:08 <kparal> ack 18:30:24 <tflink> #agreed 966784 - RejectedFreezeException - This may not be clear to users, but it is by design. If anaconda devs want to change the dialog, please re-propose. 18:30:34 <tflink> #topic (881403) Anaconda doesn't correctly infer if system clock shows UTC or local time 18:30:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=881403 18:30:39 <tflink> #info Proposed Freeze Exceptions, anaconda, POST 18:31:23 <adamw> this is kinda a bug that time forgot 18:31:29 <adamw> vpodzime posted a patch for review back in january 18:31:34 <adamw> i keep pinging it 18:31:48 <adamw> but this is one quite a few people reported for f18, i think we really want the fix in f19 final if possible 18:32:56 <adamw> so, +1 18:33:49 <kparal> +1 per adamw's summary 18:33:58 <tflink> sorry, took a while to read 18:35:21 <tflink> proposed #agreed 881403 - AcceptedFreezeException - This was a commonly reported issue in F18 and a fix has been in the works for a while now. A tested fix would be considered after freeze. 18:35:51 <adamw> ack 18:36:37 <kparal> ack 18:37:30 <tflink> #agreed 881403 - AcceptedFreezeException - This was a commonly reported issue in F18 and a fix has been in the works for a while now. A tested fix would be considered after freeze. 18:37:38 <tflink> #topic (963958) dialog-warning-symbolic.svg (used as the 'warning triangle' emblem in anaconda) is now grey; if anaconda wants the old orange one, anaconda should ship it 18:37:42 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=963958 18:37:44 <tflink> #info Proposed Freeze Exceptions, anaconda, VERIFIED 18:37:48 <tflink> +1 - this has confused many people so far 18:37:59 <adamw> it's already in 19.30.1 so...:) 18:38:00 <adamw> +1 18:38:00 <tflink> "there's no warning there, just red text" 18:38:05 <tflink> well, that too 18:38:22 <kparal> +1 18:39:06 <tflink> proposed #agreed 963958 - AcceptedFreezeException - This fixes a visual issue that confused many people in beta. A tested fix would be considered after freeze. 18:39:13 <kparal> ack 18:39:54 <adamw> ack 18:39:57 <tflink> #agreed 963958 - AcceptedFreezeException - This fixes a visual issue that confused many people in beta. A tested fix would be considered after freeze. 18:40:06 <tflink> #topic (967682) Check mark used to indicate selected target disks on Installation Destination is not sufficiently obvious 18:40:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=967682 18:40:11 <tflink> #info Proposed Freeze Exceptions, anaconda, NEW 18:41:07 <adamw> +1, this also has been confusing people. 18:41:13 <kparal> good ones 18:41:20 <adamw> dunno whether anaconda guys agree, but if they do, it obviously makes sense to fix it in final 18:41:21 <kparal> +1 18:41:59 <tflink> +1 18:42:55 <tflink> proposed #agreed 967682 - AcceptedFreezeException - This would eliminate a workaround required for nfs3 repos at install time. A tested fix would be considered after freeze. 18:43:55 <kparal> nfs3? 18:44:09 <adamw> nack 18:44:10 <tflink> nfsv3? 18:44:21 <tflink> crap, I'm reading the wrong bug again 18:44:22 <adamw> this is nothing to do with nfs. 18:44:24 <adamw> heh 18:44:42 <adamw> .fire tflink moving to St. Cuthbert's Home for the Terminally Confused 18:44:42 <zodbot> adamw fires tflink moving to St. Cuthbert's Home for the Terminally Confused 18:44:42 <kparal> we're talking about checkmark icon, aren't we? 18:45:09 <tflink> kparal: I was reading 968023 18:47:03 <tflink> proposed #agreed 967682 - AcceptedFreezeException - This would fix a decent amount of confusion regarding disk selection in the UI. A tested fix would be considered past freeze. 18:47:10 <kparal> ack 18:48:08 <adamw> ack 18:48:11 <tflink> #agreed 967682 - AcceptedFreezeException - This would fix a decent amount of confusion regarding disk selection in the UI. A tested fix would be considered past freeze. 18:48:15 <tflink> #topic (968023) NFSv3 mount of installation repository fails unless 'nolock' option is passed 18:48:18 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968023 18:48:21 <tflink> #info Proposed Freeze Exceptions, anaconda, POST 18:48:23 <tflink> +1 18:48:50 <tflink> proposed #agreed 968023 - AcceptedFreezeException - This would eliminate a workaround required for nfs3 repos at install time. A tested fix would be considered after freeze. 18:49:03 <tflink> now it makes sense :) 18:51:06 <adamw> ack 18:51:23 * kparal just notes that this might break a lot of other nfs-related stuff 18:51:34 <tflink> kparal: how so? 18:51:40 <adamw> how do you mean 'this'? 18:51:43 <tflink> if the mount fails otherwise 18:51:46 <adamw> do you mean the fix, or the bug? 18:51:52 <kparal> ok, but can the fix break nfs4? 18:51:53 <tflink> oh, the bug I can see 18:52:11 <adamw> kparal: no, I don't think so. 18:52:22 <kparal> ok 18:52:26 <adamw> i can double check. 18:52:28 <tflink> I thought that the fix would only use nolock for the nfs3 attempt 18:52:37 <kparal> ack 18:52:40 <adamw> as written i think it uses nolock for all nfs mounts 18:52:49 <tflink> #agreed 968023 - AcceptedFreezeException - This would eliminate a workaround required for nfs3 repos at install time. A tested fix would be considered after freeze. 18:52:50 <adamw> but i don't think that'll break nfsv4 mounts (though it may mean locking is less robust than it could be) 18:52:59 * adamw will check nfsv4 mounts still work with the fix 18:53:22 <tflink> 5 minutes til' the 3 hour mark 18:53:33 <tflink> we've gotten through all of the anaconda FEs 18:53:40 <tflink> there are 4 other proposed FEs left 18:53:48 <adamw> non-anaconda ones are less important 18:53:53 <adamw> since nothing else is frozen yet 18:54:00 <adamw> so we could leave it here 18:54:34 <tflink> other thoughts? 18:54:39 <kparal> +1 18:55:12 <tflink> ok, moving on to 18:55:17 <tflink> #topic Open Floor 18:55:27 <tflink> Anything else to bring up today? 18:55:58 <adamw> nope 18:57:00 * tflink sets fuse for [0,5] years 18:57:32 <tflink> probably closer to the 0 on that, though 18:58:05 <adamw> kparal: nfsv4 mounts still work with the fix for 968023. 18:58:18 <adamw> they have the parameter 'local_lock=none' which was presumably translated from nolock. 18:59:14 <adamw> but basically, it works. 19:02:24 <adamw> hum, actually, local_lock is set to 'none' even without the fix. so it looks like thre's no difference for nfsv4. 19:02:25 <tflink> Thanks for coming, everyone! 19:02:29 <adamw> thanks tflink! 19:02:37 * tflink will send out minutes shortly 19:02:49 <tflink> #endmeeting