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