16:00:43 <tflink> #startmeeting f19final-blocker-review-8
16:00:43 <zodbot> Meeting started Mon Jun 24 16:00:43 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:43 <tflink> #meetingname f19final-blocker-review-8
16:00:43 <tflink> #topic Roll Call
16:00:43 <zodbot> The meeting name has been set to 'f19final-blocker-review-8'
16:00:58 <tflink> Who's ready for some blocker review?
16:01:00 * nirik waves
16:01:06 * kparal waves twice
16:02:29 * jreznik is here
16:03:59 * tflink waits a few more minutes in case more people join
16:04:11 <tflink> any volunteers for secretarialization?
16:04:14 <adamw> yo
16:04:18 <adamw> here
16:05:45 * Viking-Ice ahoy
16:06:09 <tflink> ok, I think we have enough to get this party started
16:06:11 <tflink> any volunteers for secretarialization?
16:06:38 <adamw> that's what the yo was for
16:06:43 <adamw> it was a dual-purpose yo
16:06:46 <adamw> efficiency, y'know
16:06:47 <tflink> ah, wasn't sure
16:06:52 <tflink> efficiency?
16:06:57 <tflink> :)
16:07:03 <tflink> anyhow, boilerplate time!
16:07:08 <tflink> #topic Introduction
16:07:13 <tflink> Why are we here?
16:07:13 <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:07:18 <tflink> #info We'll be following the process outlined at:
16:07:18 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:23 <tflink> #info The bugs up for review today are available at:
16:07:23 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:28 <tflink> #info The criteria for release blocking bugs can be found at:
16:07:28 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria
16:07:31 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria
16:07:34 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:07:37 <tflink> #info Up for review today, we have:
16:07:40 <tflink> #info 3 Proposed Blockers
16:07:40 <tflink> #info 3 Accepted Blockers
16:07:40 <tflink> #info 14 Proposed Freeze Exceptions
16:07:40 <tflink> #info 20 Accepted Freeze Exceptions
16:08:00 <tflink> if there are no objections, we'll start with the proposed blockers
16:08:07 <tflink> #topic (964443) Fedora 19 Live Alpha and Beta hangs in boot on HP Envy 23
16:08:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=964443
16:08:12 <tflink> #info Proposed Blocker, kernel, NEW
16:08:41 <adamw> anyone heard of anything like this with any other systems?
16:08:55 <adamw> "Fedora 19 boots and runs correctly.
16:08:56 <adamw> After ca. 15min the system hangs"
16:09:00 <adamw> reliably reproducible
16:09:03 * satellit_e listening
16:09:20 <tflink> not really, no
16:09:20 <Viking-Ice> nothing in logs?
16:10:05 <adamw> nothing i could turn up
16:10:18 <adamw> had him ssh in from another system and try tailing /var/log/messages and journalctl -f, nothing looks relevnat
16:10:33 <adamw> see comments 7 and 9
16:11:03 <adamw> the last message is always "Started Cleanup of Temporary Directories." but i think that's just, y'know, the last message of startup, not actually the cause of the bug
16:11:34 <Viking-Ice> this is punt we need more data
16:11:46 <adamw> for me it's -1 unless we have any other reports
16:11:52 * jreznik is running f19 on several *real* hw, no issues similar to this one
16:11:55 <tflink> yeah, -1 here as well
16:11:58 <adamw> it's been filed for over a month, if it was a major issue  you'd think we'd hear more
16:12:00 * kparal agrees
16:12:10 <adamw> haven't seen anything like it on test@ or forums
16:12:24 <jreznik> -1 too, seems to be hw specific and we would see more reports if it would be more widespread
16:12:39 <Viking-Ice> could be screensaver/screen dimming kicking in after those 15 minutes locking things up
16:12:49 <Viking-Ice> -1 here as well
16:12:52 <adamw> Viking-Ice: point, or one I just thought of, could be it takes that long to overheat for some reason
16:13:01 <adamw> i'll ask him to try disabling screensaver / screen lock
16:13:22 <Viking-Ice> in anycase seems to be pretty isolated case
16:13:27 <tflink> proposed #agreed 964443 - RejectedBlocker - While unfortunate, there have not been enough reports of this bug to indicate that it is widespread enough to justify blocking release of F19 final.
16:13:28 <nirik> are there any timer jobs these days that could be hitting?
16:13:36 <Viking-Ice> ack
16:13:40 <jreznik> ack
16:13:54 <kparal> ack
16:13:56 <nirik> ack
16:14:27 <tflink> #agreed 964443 - RejectedBlocker - While unfortunate, there have not been enough reports of this bug to indicate that it is widespread enough to justify blocking release of F19 final.
16:14:34 <tflink> #topic (974811) NetworkManager dispatchers dbus services misconfiguration
16:14:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=974811
16:14:39 <tflink> #info Proposed Blocker, NetworkManager, NEW
16:15:28 <Viking-Ice> this renaming stuff is causing problems
16:15:35 <kparal> this breaks dnssec validation and any applications that rely on the dispatcher, according to jklimes
16:15:44 <kparal> an easy workaround: enable the service manually
16:15:51 <Viking-Ice> first the incorrect dbus file name in the unit and now the missing preset entry for that new name
16:16:17 * adamw reading
16:16:29 <Viking-Ice> we should pull this one in for final http://koji.fedoraproject.org/koji/buildinfo?buildID=429021
16:16:32 * nirik is +1FE, but don't think it's blocker worthy.
16:16:38 <Viking-Ice> "Rename nm_dispatcher to NetworkManager-dispatcher in default preset (#977433)"
16:16:59 * jreznik feels the same as nirik
16:17:03 <adamw> i'm no expert on the area, but i agree with nirik
16:17:14 <adamw> "DNSSEC validation on workstations" is not particularly critpath, right?
16:17:23 <Viking-Ice> this controls the network icon in gnome right?
16:17:34 <adamw> huh? I don't think so?
16:17:39 <kparal> $ ll /etc/NetworkManager/dispatcher.d/
16:17:40 <kparal> total 21k
16:17:40 <kparal> -rwxr-xr-x. 1 root root 175 Feb 20 15:53 00-netreport
16:17:40 <kparal> -rwxr-xr-x. 1 root root 335 Jul 20  2012 04-iscsi
16:17:40 <kparal> -rwxr-xr-x  1 root root 111 Apr 21 18:19 10-sendmail
16:17:41 <kparal> -rwxr-xr-x  1 root root 933 Jun  3 16:09 11-dhclient
16:17:42 <nirik> not that I know of no.
16:17:42 <kparal> -rwxr-xr-x. 1 root root 317 Sep 11  2012 20-chrony
16:17:45 <kparal> Fedora 18
16:18:11 <nirik> it just is used for dnssec-trigger... so worst case, you will not get dnssec answers, which might be a security issue, but... blocking release?
16:18:14 <adamw> kparal: does sendmail actually not work without it?
16:18:21 <Viking-Ice> anyway +1 FE
16:18:24 <dgilmore> +1 to FE
16:18:29 <Viking-Ice> this is fixed in the preset file
16:18:36 <nirik> those are likely just 'send email, since you are on line now'
16:18:40 <kparal> adamw: it seems to be restarting sendmail on network change
16:18:43 <adamw> I'm +1 FE for the preset file fix, that seems reasonable
16:18:53 <nirik> which would happen later in a regular queue run
16:18:53 <adamw> i am more worried about poking NM in any way at this point
16:19:01 <kparal> the dhclient script might be more important
16:19:04 <adamw> is any change to NM envisaged here? Or just the systemd preset fix?
16:19:11 <nirik> just the preset from what I can see.
16:19:26 <adamw> ok, +1 FE for that
16:19:30 <Viking-Ice> well I dont know if Dan fixed the missing dbus file issue
16:19:37 <dgilmore> adamw: seems that the needs for the dispatcher are post install, and can be fixed in an update. im not aware of any criteria that it blocks
16:20:09 <adamw> dgilmore: yeah, i'm not sure we *really* need to fix this for release images, but eh, maybe someone would use dnssec on a live or something
16:20:18 <nirik> they could.
16:20:20 * adamw would really like not to poke NM at this point
16:20:26 * nirik uses dnssec-trigger, it's nifty
16:20:42 <nirik> if we pull systemd for other issues, we could pull the preset too.
16:21:13 <tflink> proposed #agreed 974811 - RejectedBlocker AcceptedFreezeException - The issues described are not critpath, not 100% applicable to live images and could be fixed with an update. Thus it doesn't qualify as a release blocking issue but a tested fix would be considered after freeze.
16:21:15 <adamw> i don't mind just pulling a systemd which *only* adds a preset. that Can't Possibly Go Wrong (tm)
16:21:27 <adamw> i would be much more worried about a systemd that did anything else.
16:21:28 <adamw> ack
16:21:32 <adamw> key word 'considered'
16:21:42 <jreznik> ack
16:21:42 <nirik> ack
16:21:44 * nirik nods.
16:21:44 <Viking-Ice> ack
16:22:01 <tflink> #agreed 974811 - RejectedBlocker AcceptedFreezeException - The issues described are not critpath, not 100% applicable to live images and could be fixed with an update. Thus it doesn't qualify as a release blocking issue but a tested fix would be considered after freeze.
16:22:09 <tflink> #topic (973019) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 0: ordinal not in range(128)
16:22:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=973019
16:22:15 <tflink> #info Proposed Blocker, python-blivet, POST
16:23:38 <tflink> it sounds like we're starting to see more reports of this?
16:23:51 <kparal> many more
16:23:53 <kparal> +1 blocker
16:24:07 <kparal> look at See Also bugs
16:24:15 <Viking-Ice> +1
16:24:20 <Viking-Ice> blocker
16:24:21 <kparal> they are most probably dupes
16:24:24 <adamw> kparal: are you sure they're all the same?
16:24:28 <kparal> adamw: no
16:24:30 <adamw> i've been bugging anaconda guys about it but they're not sure
16:24:50 <adamw> <bcl> as far as unicode errors, IIRC those are different, but vratislav has a fix for at least some of them. But I want to take a careful look at the code first, I'm afraid we'll get into a situation where we alter what parted hands us and then try to use it later and have parted not recognize it.
16:24:52 <kparal> but they seems to be at the same stage
16:24:54 <adamw> let me see if bcl can come help out
16:25:06 <nirik> looks blockery to me...
16:25:48 <adamw> what worries me is if there are multiple unicode errors, and we arbitrarily just take a fix for one of them and it's not even the worst...just want to make sure we're going with joined up thinking here
16:26:08 <nirik> yeah.
16:26:21 <nirik> is this unicode in disk labels? or where?
16:27:09 <adamw> still waiting on bcl
16:27:16 <adamw> in the meantime: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&classification=Fedora&component=anaconda&component=python-blivet&list_id=1474576&query_format=advanced&short_desc=UnicodeDecodeError&short_desc_type=allwordssubstr
16:27:19 <kparal> I was reformatting an existing default layout, IIRC
16:29:28 <adamw> hi bcl! thanks
16:29:36 <adamw> to repost from above: what worries me is if there are multiple unicode errors, and we arbitrarily just take a fix for one of them and it's not even the worst...just want to make sure we're going with joined up thinking here
16:29:51 <adamw> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&classification=Fedora&component=anaconda&component=python-blivet&list_id=1474576&query_format=advanced&short_desc=UnicodeDecodeError&short_desc_type=allwordssubstr
16:30:02 <adamw> lists all anaconda/python-blivet bugs in fedora with "UnicodeDecodeError" in them
16:30:23 <bcl> the ones I remember seeing so far are different places in the code, so there won't be one fix to rule them all.
16:30:27 <adamw> i think kparal was proceeding on the assumption that most or all of those were the same bug and using 973019 as a 'proxy' for them, but i'm not sure that's the case
16:30:45 <adamw> what do you think we ought to do? Take them all as blockers? try and evaluate how likely we are to hit them?
16:31:05 <adamw> bearing in mind we really need fixes in and an anaconda built ideally by today or tomorrow, or wed at the _very latest_, to make release
16:31:09 <Viking-Ice> or rather how invasive will be the fix for this
16:31:14 <adamw> that too
16:32:48 <adamw> 973384 and 976576 both seem to be File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 451, in execute
16:32:49 <adamw> msg = _("Creating %(type)s on %(device)s") % {"type": self.device.format.type, "device": self.device.path}
16:33:06 <adamw> and 976630...
16:33:39 <jreznik> I'd say evaluate blockery/fe individually for each one
16:33:53 <adamw> but 973019 seems different
16:34:04 <adamw> so do we have two bugs here? 973019, and the others all the same?
16:34:56 <tflink> 965556 also seems different to me
16:35:16 <tflink> it's from text mode and isn't a unicode-as-ascii error
16:35:31 <adamw> yeah, different codec, but that's older and doesn't seem to have gotten any dupes
16:35:32 <Viking-Ice> jreznik, once we might know what might break in the process of patching this we can evaluate this
16:35:55 <adamw> Viking-Ice: there is already a patch posted for 973019 specifically, with discussion
16:36:01 <adamw> https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-June/004732.html
16:37:29 <Viking-Ice> Vratislav "I've tested this patch on live and netinst installations and nothing
16:37:29 <Viking-Ice> seemed to be broken by it."
16:37:46 <adamw> right
16:38:00 <adamw> and bcl is of the opinion that even if it breaks something it's unlikely to be worse than the tracebacks
16:38:29 <adamw> but i'd just like to pin down this question of the other bugs kparal was assuming were dupes of this
16:40:09 <bcl> ok, the _("Creating %(type)s on %(device)s") ones are dupes.
16:40:13 <adamw> ok
16:40:40 <adamw> so we basically have 973019, the 'type on device' bugs (I'll dupe those off), and 965556
16:41:40 <adamw> bcl: does it seem plausible to fix 973019 and the 'type on device' bugs in the next day or two?
16:41:40 <tflink> which it sounds like we're OK with leaving alone for now
16:42:00 <adamw> yeah, i think we should needinfo 965556 for the actual reproducer steps, and to see if it's still valid
16:42:03 <Viking-Ice> adamw, we just wait if we have to
16:42:17 <Viking-Ice> needinfo agreed
16:42:19 <adamw> sure, but it'd be nice if we don't have to
16:42:48 <bcl> adamw: no idea
16:42:56 <Viking-Ice> adamw, what do you mean? you ask if he could fix this in the next day or two and if he cant we simply slip
16:42:58 <adamw> okay
16:43:06 <adamw> Viking-Ice: i mean it'd be nice if we don't have to slip.
16:43:45 <Viking-Ice> nice indeed and pony's will fart rainbows when we eventually will release on time ;)
16:43:56 <drago01> we already slipped
16:44:05 <tflink> drago01: we meant for final
16:44:12 <drago01> ok
16:44:40 <kparal> an autodetected-czech installation doesn't crash with a completely blank disk
16:44:41 <tflink> is anyone -1 blocker on this?
16:45:03 <adamw> right, we now boil down to two bugs: 973019 and 973384
16:45:35 <adamw> since we don't actually have any other reports of 973019 so far as I can see, the blocker decision is a bit less clear, but it does seem there's some code there that is definitely Doing The Wrong Thing
16:45:42 <tflink> adamw: I thought it was 973019 and 965556
16:45:43 <adamw> bcl: what's your take on whether each should be a blocker?
16:45:52 <adamw> tflink: 965556 i'm writing off as needinfo
16:45:56 <tflink> ok
16:46:03 <adamw> 973384 is the master bug for the 'line 451' bugs now
16:46:08 <adamw> 973019 is *not* the same as those
16:47:57 <kparal> I can't reproduce bug 976576 right now
16:48:14 <kparal> even with first installation, nor with a re-installation
16:48:28 <kparal> so this might be tricky to verify
16:48:41 <kparal> oh, I'm not using Live, damn
16:49:02 <Viking-Ice> 73019, 976576 seems to be a clear blocker and
16:49:18 <Viking-Ice> 976576 falls under 976576
16:49:23 <Viking-Ice> right
16:49:27 <dan408_> hi
16:49:36 <bcl> oh hell
16:49:47 <tflink> that sounds bad ...
16:49:51 <adamw> happy joy
16:50:10 * jreznik is pretty lost now
16:50:13 <bcl> adamw: if they can be worked around by not naming your devices with unicode (yeah, I know...) then I'm not too blockerish on them.
16:50:25 <adamw> bcl: from the descriptions it doesn't sound like that's what people are doing.
16:50:27 <dan408_> bcl: i had a DVD install failure last night
16:50:31 <adamw> but it's a bit hard to be sure
16:50:31 <kparal> oh, default install crashes, reproduced 976576
16:50:40 <dan408_> i didnt get a chance to mark it
16:50:43 <adamw> jreznik: 976576 is one of the dupes of 973384
16:50:52 <adamw> can we please talk about 973384, not 976576? it will make things clearer
16:51:07 <kparal> deviceaction.py  -> +1 blocker
16:51:07 * dan408_ checks that his bug was not a duplicate
16:51:12 <adamw> bcl: yeah, if kparal hits 973384 on a default live install, it can't be to do with unicode device names, can it?
16:51:24 <kparal> adamw: the disk was newly created
16:51:34 <kparal> it's not about existing layout
16:51:39 <bcl> adamw: if he has pre-existing devices names it could be.
16:51:39 <adamw> right
16:51:43 <kparal> but it happens only if Czech is auto-selected it seems
16:51:54 <adamw> kparal: as in, you started with a brand-new virtual disk?
16:51:56 <bcl> kparal: oh. well. hrm.
16:51:58 <kparal> adamw: right
16:51:59 <adamw> so, no pre-existing device names
16:52:02 <kparal> right
16:52:06 <adamw> okay, i'm definitely +1 on 973384 then
16:52:19 <jreznik> kparal: so similar issue to the one martin fixed - with autoselected czech?
16:52:39 <kparal> jreznik: yeah, that's why I originally assumed it was not fixed completely. something with geolocation it seems
16:52:39 <adamw> kparal: can you add a comment to 973384 that explains your reproducer and makes it clear it is reproducible on a brand new disk without any crazy names or anything?
16:52:41 <bcl> you'd think our support for that would be better :)
16:52:47 <adamw> =)
16:53:00 <kparal> jreznik: Martin fixed getting timezone correctly, but it seems something else is retrieved with a broken charset
16:53:20 <dan408_> my issue was somewhat related to 973384
16:53:23 <dan408_> but not the same
16:53:40 <adamw> if all this is coming in through the geolocation stuff, then grrr us for taking it late. sigh.
16:53:54 <kparal> adamw: will do
16:54:09 <adamw> so we're down to 973019, itself, in the knowledge that we do not have other reports of this specific bug
16:54:47 <drago01> adamw: we could revert it if we cannot fix it in time
16:54:57 <drago01> adamw: and try again for f20
16:54:59 <bcl> well the tb is on either self.device.format.type or self.device.path neither of which should be related to geolocation.
16:55:05 <kparal> vpodzime seems to know what the problem is in 973019
16:55:13 <adamw> yeah
16:55:21 <adamw> it's just a question of how common the issue is likely to be
16:55:27 <adamw> c#16 says "Non ASCII characters in disk label used, only Fedora 18 system the old partitioned system, no less no more."
16:55:43 <dan408_> mine is related.
16:55:46 <adamw> bcl: can you get a read on how likely 973019 is to be encountered, based on the nature of the actual code bug?
16:55:50 <adamw> dan408_: that tells us nothing useful.
16:55:59 <dan408_> im installing from the DVD on a system that had partitions
16:56:18 <dan408_> and there is a 0 byte partition. when i try to delete it, anaconda crashes
16:56:19 <adamw> and are you hitting a traceback that matches 973019 or 973384? or has anything to do with unicode in general?
16:56:21 <dan408_> im getting the bug number
16:56:24 <dan408_> no
16:56:27 <adamw> if not, then it's not related.
16:56:29 <dan408_> but a traceback i've seen before
16:57:06 <dan408_> .bug 960794
16:57:13 <zodbot> dan408_: Bug 960794 AttributeError: 'NoneType' object has no attribute 'type' - https://bugzilla.redhat.com/show_bug.cgi?id=960794
16:57:42 <adamw> it may be worth proposing that as a blocker
16:57:50 <adamw> but it has nothing to do with the bugs we're talking about right now, so please save it
16:58:11 <bcl> adamw: if I can grab the time to look at it :)
16:58:13 <Viking-Ice> great gnome shell crashed on me gotta love it
16:58:15 <dan408_> odd, the first time i hit it it said it was creating a new bug and then it timed out
16:58:29 <adamw> Viking-Ice: shouldn't kill your apps...
16:58:48 <adamw> bcl: thanks, standing by :)
16:59:15 <adamw> my inclination is +1 on 973019, but i want to be sure we're not taking a potentially significant patch for something incredibly obscure
16:59:20 <kparal> adamw: even better, I can reproduce 973384 if you just select Czech from the list, it doesn't have to be auto-selected. which means it's not geolocation, but some program returns a different content based on locale, probably
16:59:31 <adamw> right.
16:59:36 <Viking-Ice> adamw, it threw me out this time ;(
16:59:37 <adamw> as bcl suggested.
16:59:57 <adamw> Viking-Ice: probably not Shell crashing then, but something else...if just *shell* crashes, it should just respawn itself, your session shouldn't die
17:01:02 <dan408_> bcl: okay i hit 2 different bugs on the same issue 977279 960794 i'll nominate them both adamw
17:01:09 <bcl> kparal: I just did that and am doing a RAID1 install. no crash.
17:01:16 <bcl> so something is funky here.
17:01:35 * nirik reads back up
17:01:39 <nirik> is this geoip related?
17:01:48 <kparal> nirik: we're not sure
17:01:49 <adamw> no.
17:01:52 <adamw> doesn't seem to be.
17:02:12 <nirik> ok
17:02:25 <nirik> there was a unicode issue with it a while back, but I am pretty sure we fixed it on the server end
17:03:20 <bcl> nirik: no, this has to do with disks.
17:03:37 <nirik> ok.
17:04:54 <tflink> fun, I just hit a unicode bug doing a custom part install w/ japanese
17:05:03 <tflink> trying to grab the tb
17:05:23 <kparal> bcl: hmm, I can reproduce 100%. I wonder whether it has really nothing to do with the geolocation support after all. maybe it changes the locale for some pieces?
17:05:52 <kparal> tflink: deviceaction.py ?
17:06:21 <kparal> bcl: are you using Live?
17:06:33 <adamw> bcl: are you doing a *live* install?
17:06:34 <adamw> jinx
17:08:51 <bcl> no
17:08:59 <tflink> kparal: looks like a new bug
17:09:08 <kparal> bcl: it doesn't happen with DVD
17:09:12 <tflink> well, as far as libreport is concerned
17:09:19 <tflink> .bug 977491
17:09:22 <zodbot> tflink: Bug 977491 UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 3: ordinal not in range(128) - https://bugzilla.redhat.com/show_bug.cgi?id=977491
17:09:46 <kparal> tflink: I'm quite sure it doesn't happen with DVD, I tested it several time
17:09:48 <kparal> s
17:10:12 <tflink> yeah, I was using the desktop live
17:10:24 <tflink> was I supposed to be trying that?
17:10:32 <kparal> I wanted to retrieve more info, but Debug button doesn't seem to work on Lives
17:11:00 <adamw> tflink: actually
17:11:06 <adamw> tflink: yours looks an awful lot like 973019 =)
17:11:35 <adamw> looks like the code shifted a couple of lines between 19.30.3 and 19.30.9, but looks like the same code
17:11:39 <kparal> adamw: yes, it seems the same
17:11:58 <tflink> adamw: like I said, libreport thinks it's a new bug :)
17:12:19 <kparal> so, it seems we have two winners for the blocker award ceremony
17:12:29 <adamw> tflink: code move
17:13:17 <adamw> yeah...based on current data I'd be +1 to both I guess :/
17:14:35 <Viking-Ice> +1 on both here
17:14:49 <tflink> other votes?
17:14:55 <kparal> +1 to both
17:15:02 * tflink is +1 - that was way too easy to hit
17:15:03 * nirik nods. +1 to both I guess. ;(
17:15:27 * tflink does 973019 first
17:16:16 <tflink> what criterion were we going to use for this?
17:16:17 <drago01> +1
17:16:19 <tflink> custom partitioning?
17:17:38 <jreznik> +1, seems like a lot of happening
17:17:49 <tflink> "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"?
17:18:51 <nirik> sure.
17:18:54 <adamw> yeah
17:19:01 <adamw> conditional on non-english language
17:19:27 <tflink> proposed #agreed 973019 - AcceptedBlocker - Violates the following F19 final release criterion for many live installs using non-english languages: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
17:19:40 <tflink> adamw: yeah, I just wasn't sure about the base criterion
17:19:46 <kparal> ack
17:20:20 <adamw> ack
17:20:44 <Viking-Ice> ack
17:21:08 <adamw> whew, that only took an hour +
17:21:09 <jreznik> ack
17:21:30 <tflink> #agreed 973019 - AcceptedBlocker - Violates the following F19 final release criterion for many live installs using non-english languages: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
17:21:37 <tflink> #topic (973384) UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)
17:21:40 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=973384
17:21:43 <tflink> #info ProposedBlocker, python-blivet, NEW
17:21:49 <tflink> any objections to using the same criterion here?
17:22:13 <adamw> nope, same criterion, +1
17:22:22 <nirik> +1
17:22:44 <tflink> proposed #agreed 973384 - AcceptedBlocker - Violates the following F19 final release criterion for many live installs using non-english languages: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
17:22:58 <jreznik> ack
17:23:02 <kparal> ack
17:23:36 <Viking-Ice> ack
17:23:40 <nirik> ack
17:25:00 <tflink> #agreed 973384 - AcceptedBlocker - Violates the following F19 final release criterion for many live installs using non-english languages: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
17:25:08 <tflink> OK, that's all of the proposed blockers
17:25:34 <tflink> moving on to the proposed FE that aren't NEW
17:25:43 <tflink> #topic (874381) USB stick install is running from doesn't get filtered out as an install target
17:25:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=874381
17:25:49 <tflink> #info Proposed Freeze Exceptions, anaconda, MODIFIED
17:26:31 <tflink> I thought this was fixed already
17:26:53 <adamw> it came back
17:26:57 <adamw> er
17:26:58 <tflink> although come to think of it, I think I saw this last week
17:27:00 <adamw> objection
17:27:03 <adamw> we have a new proposed blocker
17:27:24 <tflink> bzid?
17:27:26 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=960794
17:27:39 <kparal> let's discuss this one first
17:27:40 <tflink> overruled!
17:27:41 <adamw> (and 977279, though i think they're identical)
17:27:47 * tflink bangs gavel on bench
17:27:50 <Viking-Ice> let's finish working through the FE and take new blocker(s) last or maybe not..
17:29:16 <Viking-Ice> <sigh> are we going to deal with 874381 or 960794 ?
17:29:38 * kparal is +1 FE
17:29:55 <tflink> let's get through the FEs
17:29:58 <tflink> or at least try to
17:30:21 * tflink will keep an eye on time - we should hit the blockers before finishing for the day
17:30:39 <tflink> +1 FE
17:30:45 <Viking-Ice> +1 FE
17:30:53 <kparal> let's finish this one and then just to the new blocker
17:30:55 <adamw> yeah, +1 since we can't think of a problem with the change
17:31:51 <tflink> proposed #agreed 874381 - AcceptedFreezeException - While this isn't severe enough to be a release blocking issue, allowing users to install to the install media is generally unwise. A tested fix would be considered after freeze
17:32:29 <Viking-Ice> ack
17:32:44 <kparal> does this prevent installation from a local partition containing the ISO?
17:33:12 <tflink> kparal: not sure, good question
17:33:14 <kparal> which is I guess a supported use case, we have even test case for that
17:33:25 <adamw> i don't quite see
17:33:34 <adamw> the test only filters out live media
17:33:54 <kparal> ok
17:34:11 <kparal> but we should make sure to re-run https://fedoraproject.org/wiki/QA:Testcase_install_repository_Hard_drive_variation
17:34:14 <kparal> ack
17:34:15 <adamw> it doesn't just check for an iso file or anything
17:34:15 <adamw> sure
17:34:44 <adamw> oh, and this is only filtering the *install destination* screen
17:34:44 <tflink> which sounds like it would likely cause problems for that test case
17:34:48 <adamw> not the installation source spoke
17:35:02 <tflink> good point. either way, worth re-running
17:35:15 <adamw> sure
17:35:20 <tflink> #agreed 874381 - AcceptedFreezeException - While this isn't severe enough to be a release blocking issue, allowing users to install to the install media is generally unwise. A tested fix would be considered after freeze
17:36:15 <tflink> so are we wanting to discuss the new blocker(s) now or wait until the end of the review meeting?
17:36:23 <kparal> now
17:36:26 <tflink> I was going to just leave them
17:37:07 * kparal is ok with best judgement of someone who skimmed them
17:37:32 <tflink> these don't scream blocker to me
17:37:35 <tflink> but eitherway
17:37:44 <adamw> 977279 ? it's certainly worrisome
17:37:48 <adamw> it's a partitioning crash
17:37:56 <Viking-Ice> are we finished with the FE?
17:38:00 <adamw> it seems to be contingent on the presence of a disk which reports 'no media present'
17:38:08 <adamw> but at least three people have hit it...
17:38:23 <tflink> Viking-Ice: no, we're being hijacked apparently
17:38:47 <Viking-Ice> <sigh>
17:38:49 * kparal puts on his moustache
17:39:26 * Viking-Ice raises his ax
17:39:46 <tflink> #topic (977279)  poor handling of disks that report no media present
17:39:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=977279
17:39:52 <tflink> #info ProposedBlocker, anaconda, ASSIGNED
17:40:09 <tflink> do we even know how many devices do this?
17:40:15 <tflink> other than iphones
17:42:16 <kparal> it would be bad if some integrated card reader caused this
17:42:26 <kparal> maybe a card reader with a card inserted
17:42:28 <adamw> tflink: i don't really see how it's 'hijacking' to ensure we cover all proposed blockers. three days before go/no-go.
17:42:30 <jreznik> or better - any non-detachable device that could report no media? otherwise we can always ask to remove it
17:42:30 <adamw> anyhoo
17:42:33 <Viking-Ice> if this is triggered only by iphones or some other exotic device ( not attached usb stick ) I'm leaning towards -1
17:42:58 <adamw> we know at least one of the devices that triggers it is a 'usb-Generic_2.0_Reader'
17:43:03 <Viking-Ice> adamw, hijacking since we had moved into FE we could have taken new proposed blockers after that
17:43:07 <adamw> and we know Dan's is an iPhone, apparently
17:43:12 <adamw> Viking-Ice: assuming we had time...
17:43:26 <tflink> adamw: other than me saying I'd keep an eye on the time and get to the blockers before we were done? either way, let's just keep moving forward
17:43:41 <adamw> so we need to hear from one other reporter, and maybe get some details from Clyde, as I asked for
17:43:55 <adamw> it would be good to know if one has to explicitly pick the 'bad' device as a target device or not
17:43:58 <tflink> do we even have enough data to take this as a blocker right now?
17:44:07 <kparal> I'm ok with punting here
17:44:10 <adamw> i'm not sure, that would appear to be the topic of the discussion.
17:44:46 <Viking-Ice> let's punt
17:44:59 <kparal> this could be serious, if some common devices caused it. we don't know that yet, just wait if we receive more info
17:45:07 <kparal> if we don't, there's nothing we can do about it
17:45:41 <jreznik> kparal: yeah, that's the problem - common devices...
17:46:02 <kparal> jreznik: other than iphones :)
17:46:15 <adamw> note we have quite limited punting time
17:46:16 <kparal> something firmly attached
17:46:25 <jreznik> kparal: iphone is not a problem - you just detach it...
17:46:30 <kparal> yes
17:46:42 <kparal> but you can't detach an integrated card reader
17:46:47 <adamw> this week is go/no-go. i would really like to have our 'hopefully final' rc built tomorrow, absolute latest is wed...so, yeah. anyhow. i'm okay with punting, but we'd definitely need to look into it proactively
17:46:51 <adamw> kparal: in a laptop, right
17:46:56 <jreznik> kparal: but you can insert card
17:47:06 <kparal> adamw: if we punt, it doesn't stop us from creating a RC
17:47:10 * tflink is starting a live isntall with empty usb card reader attached
17:48:40 <adamw> kparal: no, but if we decide this is a blocker on wednesday, we're basically punting.
17:48:49 <kparal> I'm quite sure we did a few installs on a T420 notebook, which should have a card reader
17:48:55 * adamw has an ipod touch 1st gen lying around here. wonder if that'd do the trick.
17:48:57 <tflink> instead of waiting for this test, how about we figure out what would need to happen to take this as a blocker
17:49:29 <adamw> tflink: for me the key questions are 'what exactly are the two reproducing devices aside from dan's iphone?' and 'do you have to explicitly select the bad device as a target disk or not?'
17:49:30 <kparal> tflink: we would need to learn that it can't be worked around on some machines, or that it affects many machines
17:49:55 <adamw> especially the second one. if the answer to that is 'the bug doesn't happen unless you explicitly select the device', that's pretty much -1 for me
17:51:05 <adamw> dan408_: yo, can you answer that one?
17:52:04 <adamw> anyhow, if no-one can think of anything else to ask i think we have a puntin' plan
17:54:16 <tflink> installation with empty usb reader seems fine
17:54:32 <tflink> i had a bunch of empty disks show up in custom partitioning
17:54:44 <tflink> which makes me want to try this again with 1 disk and autopart
17:54:51 <adamw> tflink: it may well be that differenty usb readers look at things differently
17:55:04 <tflink> adamw: sure, it was a point of reference
17:55:50 <tflink> so, we're punting to find out what devices cause this and what the workarounds are, if there are any
17:56:23 <adamw> that's the plan
17:56:27 <tflink> proposed #agreed 977279 - This looks like it could be problematic but we need more data on the involved devices and any potential workarounds before making a decision on blocker status
17:56:30 <adamw> ack
17:56:35 <Viking-Ice> ack
17:56:47 <tflink> #agreed 977279 - This looks like it could be problematic but we need more data on the involved devices and any potential workarounds before making a decision on blocker status
17:56:59 <jreznik> ack but I'd if this would affect readers in laptops, that would probably mean gazzilions of reports, so I'm more not a blocker
17:57:03 <tflink> OK, moving back to proposed FEs
17:57:51 <tflink> #topic (976931) Make name and icon more understandable
17:57:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=976931
17:57:52 <tflink> #info Proposed Freeze Exceptions, bijiben, MODIFIED
17:58:04 <tflink> If this is the only change in the package, I'm OK with FE
17:58:12 <kparal> bijiben was removed from Live, no?
17:58:19 <tflink> it isn't all that obvious what bijiben is
17:58:26 <tflink> not sure, was it?
17:58:45 <Viking-Ice> if it was removed -1 and it can be pulled in via 0day
17:58:57 <tflink> yep, not on TC6 desktop live
17:59:07 <kparal> I think that mclassen mentioned that, as part of the size trimming
17:59:18 <nirik> yeah, it's out now.
17:59:21 <kalev> it's gone from Live, but still on the DVD
17:59:22 <adamw> Viking-Ice: it's on the DVD install
17:59:31 <nirik> ah right.
17:59:34 <Viking-Ice> +1 FE
17:59:38 <adamw> tflink: "it isn't all that obvious what bijiben is" <--- that's the bug =)
17:59:47 <kparal> desktop file change -> +1 FE
17:59:50 <tflink> adamw: thanks, I kinda figured that out
17:59:51 <nirik> sure, +1 FE... it's a minor change, but looks fine
17:59:57 <kalev> I personally think it would make sense to either do the rename in the base repo, or not do at all -- it can be confusing if 0-day updates rename something.
18:00:08 <adamw> it does kinda jump out at you after a dvd install, that's why i filed it. +1 obviously
18:01:22 <tflink> proposed #agreed 976931 - AcceptedFreezeException - bijiben is on the DVD and it would be nice to have the name change in the base repos. A tested fix would be considered after freeze.
18:01:29 <adamw> ack
18:01:33 <Viking-Ice> ack
18:01:37 <kparal> ack
18:01:38 <jreznik> ack
18:01:39 <tflink> #agreed 976931 - AcceptedFreezeException - bijiben is on the DVD and it would be nice to have the name change in the base repos. A tested fix would be considered after freeze.
18:01:51 <tflink> #topic (954054) [abrt] gnome-shell-3.8.1-1.fc19: _gdk_x11_display_error_event: Process /usr/bin/gnome-shell was killed by signal 5 (SIGTRAP)
18:01:55 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=954054
18:01:57 <tflink> #info Proposed Freeze Exceptions, clutter, MODIFIED
18:02:34 <tflink> do we have any idea how common this is?
18:03:38 <kparal> and why does it have security keyword?
18:03:41 <adamw> just a sec, lemme double check which it is
18:04:05 <adamw> i think the problem is that if shell crashes on the unlock screen, it auto-respawns
18:04:11 <adamw> and hence effectively unlocks itself
18:04:27 <kparal> aha
18:04:34 <adamw> "It was immediately after resuming, I think the unlock prompt came up ... and then it crashed before I entered the password and I was in and gnome shell was working as expected."
18:05:01 <adamw> shouldn't really affect lives except for the more unusual persistent storage / valuable user account case i guess...
18:05:27 <kparal> I'm not sure if we want to update clutter
18:05:28 <Viking-Ice> yeah
18:05:35 <Viking-Ice> -1
18:05:36 <Viking-Ice> here
18:05:42 <tflink> FWIW, it seems to be a pretty  minor fix
18:05:45 <kparal> but mclasen probably knows what he's doing
18:05:52 <tflink> https://bug701974.bugzilla-attachments.gnome.org/attachment.cgi?id=246475
18:06:04 <adamw> let me see if he's around and wants to argue the case
18:06:09 <kparal> tflink: are we sure the new version contains just the fix?
18:06:22 <tflink> kparal: if we trust the rpm changelog, yes
18:06:31 <tflink> http://koji.fedoraproject.org/koji/buildinfo?buildID=428866
18:06:33 <kalev> the change here is small and also ACKd by the upstream maintainer: https://bugzilla.gnome.org/show_bug.cgi?id=701974#c3
18:06:49 <tflink> kalev: the question was more if this was the only change between the two builds
18:06:54 <kalev> looking at the retrace server output, it's not very high on the top crashers, https://retrace.fedoraproject.org/faf/problems/200173/
18:07:03 <kalev> 130 crashes so far.
18:07:46 <tflink> I could go either way, it'd be nice to have fixed but it's a little late for clutter fixes that don't impact lives
18:07:54 <drago01> this is a rather obvious fix
18:07:59 <tflink> don't impact lives in most situations, anyways
18:08:50 <tflink> drago01: not sure whether the obvious-ness of a fix is relevent here, though
18:09:07 <mclasen> hi
18:09:12 <drago01> tflink: it means the likelyhood of exploding is almost none
18:09:27 <adamw> halfline: drago01: mclasen: so we see the value of the fix but we note that it's unlikely to affect lives (hence can be fixed quite well with a post-release update) and it's quite late at this point to be poking things unnecessarily (go/no-go on thursday)
18:09:27 <tflink> drago01: sure, but we've said that about fixes before
18:09:29 <Viking-Ice> yeah almost
18:09:29 <adamw> any thoughts?
18:09:37 <adamw> yeah, Nothing Can Possibly Go Wrong ;)
18:09:52 <mclasen> sure, it can be fixed post-release
18:09:58 <tflink> days before go/no-go, I get much more paranoid about fixes we don't _need_ in things that can't be fixed with an update
18:10:10 <drago01> tflink: yeah but can be zero day or post release as well
18:10:19 <mclasen> but the fix is really pretty safe - it essentially copies a few checks from the gtk3 xi2 code to the equivalent clutter code
18:10:53 <tflink> so the question comes down to how paranoid do we want to be?
18:10:59 <mclasen> I just built the update now because florian was asking if we could get the fix into f19
18:11:04 <adamw> still, if you're not really desperate to have it in the frozen package set / release images, we might prefer just to go with the no-pokey-plan
18:11:15 <adamw> we have definitely been bitten by things that couldn't possibly go wrong before
18:11:25 <tflink> if we slip, I'm definitely +1
18:11:35 <Viking-Ice> you mean when we slip
18:11:46 <Viking-Ice> sure +1 then ;)
18:11:50 <tflink> no, I mean if. the decision hasn't been made yet
18:11:52 <drago01> tflink: how about we try not to slip this time
18:12:19 <tflink> drago01: who said we were trying to slip?
18:12:19 <Viking-Ice> tflink, those anaconda bugs discussed earlier have not been fixed yet either so....
18:12:37 <tflink> is anyone strongly +1 to taking this right now?
18:13:06 <tflink> otherwise, I say punt and move on or conditionally accept if we slip
18:13:12 <adamw> +1 on that
18:13:18 <adamw> Viking-Ice: we're working on 'em.
18:13:27 <kparal> tflink: +1
18:13:33 <jreznik> tflink: yep
18:13:37 <Viking-Ice> tflink, yep
18:14:47 <tflink> proposed #agreed 954054 - While it's too close to go/no-go to take this as FE at the moment, it would be accepted in the case that we end up slipping F19 final as long as it goes into the first post-slip spin.
18:14:51 <tflink> wording OK?
18:15:08 <Viking-Ice> yeah sure why not ack
18:15:09 <jreznik> works for me, ack
18:15:11 <tflink> tried to word it such that we don't have to re-discuss if slip happens
18:15:20 <jreznik> tflink: good idea :)
18:15:34 * nirik thinks it could just be FE and we decide not to use it unless... but sure, whatever. symantics.
18:15:46 <kparal> ack
18:15:54 <tflink> #agreed 954054 - While it's too close to go/no-go to take this as FE at the moment, it would be accepted in the case that we end up slipping F19 final as long as it goes into the first post-slip spin.
18:17:01 <kparal> oh, there's another gnome-shell proposed FE
18:17:16 <kparal> that changes things a bit, if we accept it, we can easily accept two patches
18:17:46 <kparal> we would need to retest everything anyway
18:17:48 <adamw> fair point
18:18:20 <tflink> #topic (977472) dragonegg broken dep in F19
18:18:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=977472
18:18:20 <tflink> #info Proposed Freeze Exceptions, dragonegg, NEW
18:18:30 <tflink> I assume this isn't on the DVD
18:18:57 * kparal checks
18:19:06 <drago01> it isn't
18:19:06 <tflink> the update is available, BTW - it just wasn't marked in bodhi
18:19:36 <Viking-Ice> zero day update then
18:19:39 <tflink> yep
18:19:42 <kparal> it isn't
18:19:43 <adamw> yep
18:19:45 <adamw> -1
18:19:47 <kparal> -1
18:19:56 <Viking-Ice> -1
18:20:02 <adamw> for f18 we took a bunch of these to get the release repos 100% consistent
18:20:09 <adamw> but i don't think there's any chance of that for f19, so not worth fiddling with
18:20:16 <tflink> proposed #agreed 977472 - RejectedFreezeException - dragonegg isn't on the DVD or live media and could be fixed with a post-release update.
18:20:21 <Viking-Ice> ack
18:20:24 <adamw> ack
18:20:41 <tflink> #agreed 977472 - RejectedFreezeException - dragonegg isn't on the DVD or live media and could be fixed with a post-release update.
18:20:56 <tflink> #topic (914942) [abrt] gnome-shell-3.7.90-1.fc19: g_str_hash: Process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV)
18:20:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=914942
18:21:01 <tflink> #info Proposed Freeze Exceptions, gnome-shell, ON_QA
18:21:28 <kparal> this seems to be hit by quite a few people
18:21:39 * kparal looks for faf report
18:22:20 <mclasen> yeah, thats a frequent crash
18:22:30 <tflink> yeah, this feels much more +1 FE
18:22:37 <tflink> we already have +3 inbug
18:22:42 <drago01> mclasen: is this the "gtkicontheme is not threadsafe" thing?
18:23:03 <kparal> 1100 reports
18:23:06 <tflink> which means we should have taken that clutter bug as FE :-/
18:23:14 <adamw> does the same update fix both?
18:23:22 <drago01> no
18:23:28 <mclasen> drago01: no, this is a reentrancy issue when reloading icon themes
18:23:31 <adamw> no, this is gtk3
18:23:42 <drago01> mclasen: ok
18:23:46 <adamw> so actually makes sense still.
18:23:53 <adamw> i'm still +1 to this given the prevalence.
18:24:05 <adamw> (and the fact you can actually hit it on the live, by the looks of it).
18:24:08 <kparal> +1 FE. and re-discuss the previous gnome-shell bug, let's take it in as well
18:24:09 <tflink> how big is the change?
18:24:52 <mclasen> not sure what answer you are looking for, but it is a fairly straightforward change, moving a signal emission to an idle
18:24:57 <mclasen> not a one-liner, though
18:25:44 <kparal> https://retrace.fedoraproject.org/faf/problems/907952/
18:25:46 <kparal> https://retrace.fedoraproject.org/faf/problems/783527/
18:25:51 <kparal> + a few more linking to this bug
18:25:54 <Viking-Ice> "
18:25:54 <Viking-Ice> While this doesn't qualify as a release blocker, it would be nice to have the fix in the base repo to avoid crashes when applying 0-day updates."
18:26:01 <adamw> kparal: why would we take the gnome-shell bug because we're taking this?
18:26:13 <adamw> kparal: this is fixed in a different package (gtk3), and it's a crasher you can actually hit on the live
18:26:17 <Viking-Ice> I'm leaning towards +1 here and pull in the other one as well since we are pulling in this one
18:26:23 * adamw doesn't see the relevance
18:26:30 <kparal> adamw: ah, this is fixed in a different package, I didn't notice
18:26:44 <kparal> in that case I take it back
18:27:03 <mclasen> the fixes are in clutter and gtk3, respectively
18:27:15 <mclasen> both bugs materialize as gnome-shell crashes, though
18:27:35 <adamw> okay, so for clarity, i'm still +1 to this bug (gtk3), -1 to the other (clutter).
18:28:06 * kparal nods
18:28:22 <dgilmore> im with adamw
18:28:23 <tflink> proposed #agreed 914942 - AcceptedFreezeException - While this isn't severe enough to block release of F19 final, it could cause problems on live media and post-install. A tested fix would be considered after freeze.
18:28:24 <dan408_> mclasen: in regards to your email yesterday, there are more things that depend on GConf2, like pidgin
18:28:36 <Viking-Ice> ack
18:28:37 <kparal> ack
18:28:40 <dan408_> ack
18:28:43 <adamw> ack
18:28:48 <tflink> #agreed 914942 - AcceptedFreezeException - While this isn't severe enough to block release of F19 final, it could cause problems on live media and post-install. A tested fix would be considered after freeze.
18:28:58 <mclasen> dan408_: thats not relevant for the desktop spin, though...and also not relevant for this channel :-)
18:29:05 <tflink> #topic (976935) mysqld.service is disactivated on upgrade from F18 to F19
18:29:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=976935
18:29:09 <dan408_> yeah my bad
18:29:10 <tflink> #info Proposed Freeze Exceptions, mariadb, ON_QA
18:29:50 <adamw> this is one of those things we should've checked earlier, it was on my todo list forever
18:30:07 <adamw> i'm still not 100% clear if fedup can actually successfully do a media-based upgrade yet
18:30:23 <dgilmore> im -1 to blocker of FE
18:30:31 <Viking-Ice> same here
18:30:49 <adamw> it's not proposed as a blocker, only FE
18:30:50 <dgilmore> there have been lots of cases the last few releases where things enabled were disabled on upgrade
18:31:00 <dgilmore> adamw: -1 to fe
18:31:07 <Viking-Ice> -1 FE
18:31:10 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=976935#c5 explains the rationale here, i'm not married to it, if people are -1 that's okay by me
18:31:21 <adamw> just thought it was worth bringing up
18:31:37 <tflink> are there also problems installing mariadb?
18:31:42 <adamw> as they've already screwed up the fix for this once and broken net installs, i can certainly see -1...
18:31:50 <tflink> .bug 975348
18:31:53 <zodbot> tflink: Bug 975348 FC19-TC3 TC4 TC5 netinstall mariadb-server - https://bugzilla.redhat.com/show_bug.cgi?id=975348
18:31:56 <adamw> tflink: kinda: the first attempt to *fix* this, mariadb-blah-blah-3, actually broke net installs.
18:32:11 <adamw> -4 should fix this without stuffing up installs, but since they managed to get it wrong once, y'know...
18:32:41 <adamw> might be best to make it a 0-day. at least we know 5.5.31-1 doesn't break anything hideously.
18:33:01 <tflink> sounds like we're mostly -1
18:33:20 <dgilmore> adamw: yeah, with a release note, it should be obvious to a sysadmin that mariadb is not running post upgrade
18:33:38 <tflink> breaking mysql upgrade on the media upgrade case isn't too bad - I can't think of too many systems that would have mysql/mariadb without network access
18:34:02 <adamw> yeah, point.
18:34:41 <Viking-Ice> well arguably this is the correct behavior since we are forcing migration upon users, fesco should never have agreed to this migration process without banning/dropping mysql in the process...
18:34:57 <adamw> way off topic.
18:35:09 <Viking-Ice> so it's better that both wind up disabled and the admin has to enable start mariadb so he notices the changes
18:35:11 <tflink> proposed #agreed 976935 - RejectedFreezeException - While this could cause problems with media sourced upgrades, that was deemed too much of a corner case to take new builds post freeze and network upgrades will function post-release once the update hits stable
18:35:33 <jreznik> ack
18:35:33 <tflink> we have less than 30 minutes left until the 3 hour mark
18:35:36 <Viking-Ice> ack
18:35:44 <adamw> ack
18:35:55 <kparal> ack
18:36:05 <adamw> Viking-Ice: the service is still called mysqld.service , so just having to enable it isn't going to necessarily clue anyone in.
18:36:13 <tflink> #agreed 976935 - RejectedFreezeException - While this could cause problems with media sourced upgrades, that was deemed too much of a corner case to take new builds post freeze and network upgrades will function post-release once the update hits stable
18:36:20 <Viking-Ice> adamw, what!
18:36:24 <Viking-Ice> <sigh>
18:36:30 <tflink> #topic (962009) f19 initial-setup didn't support mate-window-manager
18:36:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=962009
18:36:36 <tflink> #info Proposed Freeze Exceptions, initial-setup, ASSIGNED
18:36:39 <tflink> crap
18:36:41 <tflink> #undo
18:36:41 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x122da3d0>
18:36:44 <tflink> #undo
18:36:44 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x105ceb50>
18:36:46 <drago01> Viking-Ice: that's why it is a drop in replacement .... the user shouldn't really notice a difference
18:36:46 <tflink> #undo
18:36:46 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1057c1d0>
18:36:57 <tflink> #topic (972881) Suspend is not working when laptop's lid is closed
18:37:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=972881
18:37:03 <tflink> #info Proposed Freeze Exceptions, mate-power-manager, MODIFIED
18:37:11 <Viking-Ice> drago01, aha
18:38:27 <Viking-Ice> correct way would have to ship separated mariadb.service and just have a symbolic link mysqld.service for backwards compatibility
18:38:38 <Viking-Ice> not that it matters the damage is done
18:39:47 * adamw vaguely recalls this update getting a -1
18:39:58 <tflink> what are the symptoms of this? suspend not working?
18:40:12 <adamw> yeah, in MATE, when you close the laptop lid. aiui.
18:40:24 <jreznik> not sure it's really fixed
18:40:31 <tflink> that -1 sounds misguided - it also reqires a selinux-policy update
18:40:54 <tflink> sounds like it could be misguided, anyways
18:40:58 <adamw> and at least the -1 didn't say it got any worse
18:41:08 <rdieter> hi
18:42:09 <jreznik> rdieter: hi, we are just talking about mate suspend bug
18:42:10 <tflink> but I think I'm -1 on this as it could be fixed with an update
18:42:10 <adamw> suspending live images is always a bit dodgy, but eh, it's only MATE anyway, so it can't break anything critical
18:42:10 <tflink> I have a hard time seeing usecases for suspend using live media
18:42:10 <adamw> well, you CAN suspend live images if it really takes yer fancy. sometimes it works.
18:42:11 <dgilmore> tflink: i agree. yoou are not likely to suspend a livecd instance
18:42:11 <adamw> i can go either way, really.
18:42:11 <tflink> sure, you can do it. I just have a hard time justifying taking stuff past freeze for it
18:42:11 <jreznik> rdieter: do you know the update is ok or not? not sure from bug report
18:42:11 <adamw> you're trying it out on your laptop, you go to move to another room...
18:42:11 <tflink> you can do lots of things
18:42:24 <dgilmore> tflink: right not saying you cant do it. just that its not likely
18:42:43 <rdieter> jreznik: it + the dependant selinux-policy fix should do the trick
18:43:16 <dan408_> can we get the selinux-policy pushed asap?
18:43:21 <adamw> anyhow, someone toss a coin, /me will go with the majority
18:43:21 <dan408_> it is affecting a number of things
18:43:26 <adamw> -54 is stable already.
18:43:33 <rdieter> *If* you agree the issue is worth a freeze break, that is...
18:43:36 <dan408_> i am speaking with upstream regarding consolekit deprecation
18:43:51 <dan408_> it's worth a freezebreak
18:44:05 <dan408_> ConsoleKit didnt get deprecated properly
18:44:08 <tflink> -1, I think
18:44:11 <dan408_> (from mate upstream)
18:44:20 <dan408_> tflink: this is an urgent fix
18:44:25 <tflink> why?
18:44:33 <tflink> because syspend doesn't work on live media?
18:44:38 <jreznik> dan408_: it could be fixed with update
18:44:39 <dan408_> because it also affects shutdown, hibernate etc
18:44:43 <tflink> I don't see how that's a big problem
18:44:46 <dgilmore> dan408_: whats it break on install that cant be fixed with an update?
18:45:01 <jreznik> well shutdown should work on live too
18:45:03 <dan408_> dgilmore: why release something broken
18:45:03 <adamw> dan408_: er, isn't that the lightdm bug?
18:45:14 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=973618 ?
18:45:15 <dan408_> yes it's a combination of issues
18:45:21 <adamw> so, not this bug, then.
18:45:22 <dan408_> in the update rdieter requires CK
18:45:33 <dan408_> so he kills 2 birds with one stone
18:45:35 <adamw> that one is already fixed and the fix pushed stable.
18:45:37 <dan408_> please push this
18:46:04 <adamw> dan408_: does mate-power-manager 1.6.1-3 fix anything besides suspend on lid close?
18:46:18 <Viking-Ice> does any one actually suspend when running live?
18:46:39 <adamw> "mate-power-manager only acts on PM events (lid close, etc...) for active ConsoleKit sessions"
18:46:44 <adamw> Viking-Ice: that's the rationale for rejecting it
18:46:49 <dan408_> well lightdm is pushed to stable
18:47:04 <dan408_> hold on this is a combination of bugs
18:47:09 <adamw> dan408_: no it's not.
18:47:15 <dan408_> let me just catch up
18:47:16 <adamw> we have separate bugs for each issue.
18:47:40 <adamw> we are discussing 972881 specifically, and that means we are discussing mate-power-manager 1.6.1-3 and mate-power-manager 1.6.1-3 *only*.
18:47:41 <tflink> as I currently understand this issue, I'm -1
18:47:47 <dan408_> im looking at it.
18:47:47 <adamw> we are not discussing lightdm or selinux-policy.
18:47:48 <Viking-Ice> me too
18:48:09 <adamw> we are solely deciding whether to grant an FE for mate-power-manager 1.6.1-3 . that is all. so the question is, what does that update fix?
18:48:20 <dan408_> suspend on lid closed
18:48:42 <jreznik> dan408_:  and *only* suspend on lid? then -1, update
18:48:54 <adamw> anything else? rdieter, can you clarify "PM events (lid close, etc...)"? are we talking power button presses, suspend etc keys on laptops and the like?
18:49:03 <dan408_> that's all fine
18:49:04 <dan408_> -1
18:49:15 <tflink> proposed #agreed 972881 - RejectedFreezeException - While unfortunate, suspending on lid close seems like too much of a corner case to take a fix for after freeze.
18:49:25 <dan408_> ack
18:49:33 <jreznik> ack
18:49:49 <Viking-Ice> ack
18:49:51 <tflink> #agreed 972881 - RejectedFreezeException - While unfortunate, suspending on lid close seems like too much of a corner case to take a fix for after freeze.
18:50:04 <tflink> #topic (968122) SystemError : Unsupported PPC machine type: PMac
18:50:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=968122
18:50:04 <tflink> #info Proposed Freeze Exceptions, python-blivet, MODIFIED
18:50:58 <Viking-Ice> sec arch auto fe?
18:51:16 * nirik wonders how many g5's running fedora are out there.
18:51:21 <adamw> looks like it - looks like the fix only affects ppc code so can't break anything else, and makes us installable on more machines so has an obvious benefit
18:51:25 <adamw> nirik: clearly at least one. =)
18:51:26 <tflink> Viking-Ice: I don't think that such a thing exists
18:51:36 <nirik> Discontinued	August 7, 2006
18:51:39 <nirik> sad. ok.
18:52:08 <Viking-Ice> tflink, nothing more than had be discussed
18:52:10 <tflink> if the change is isolated to ppc, I'm not as worried
18:52:10 <nirik> sure, +1 FE, but sure a corner case I bet. ;)
18:52:13 <Viking-Ice> anyway +1 FE
18:52:28 <adamw> tflink: he's referring to the policy of taking secondary arch showstoppers as FEs by default, i believe. this isn't really a showstopper even for ppc, but seems safe enough to fix, and we need a new blivet for the blockers anyhow.
18:52:31 <tflink> I'm OK with +1, I guess
18:52:38 <jreznik> +1 FE
18:52:40 <adamw> tflink: it looks to be in a PPC-specific function, the patch is linked
18:52:44 <adamw> and it's a one-liner (the other lines are comments)
18:53:01 <jreznik> yep, in getPPCMacGen
18:53:22 <rdieter> adamw: (sorry got pulled away), per your previous question: yes, I believe without this fix no PM events will work, including power button, screen dim/brightness etc.
18:53:35 <adamw> sigh, timing
18:53:42 <adamw> maybe we can go back to it. or since we have 6 minutes, maybe not.
18:53:51 <tflink> proposed #agreed 968122 - AcceptedFreezeException - The change does enable greater hardware support and is isolated to ppc-specific code. A tested fix would be considered after freeze.
18:54:00 <jreznik> ack
18:54:02 <rdieter> (unless dan408_'s experiences are different that is)
18:54:12 * rdieter checks code
18:54:19 <tflink> I'm tempted to bend the 3 hour rule a bit today due to how close we are to go/no-go
18:54:26 <dgilmore> +1 to FE
18:54:32 <dgilmore> ack
18:54:35 <nirik> ack
18:54:46 <tflink> #agreed 968122 - AcceptedFreezeException - The change does enable greater hardware support and is isolated to ppc-specific code. A tested fix would be considered after freeze.
18:56:51 <tflink> do we want to go back for the mate power bug?
18:57:05 <adamw> if there's nothing more urgent
18:57:28 <tflink> those are the only 2 remaining proposed FEs that are ready to discuss
18:57:30 <jreznik> well, we have three minutes and we should go through the accepted blockers
18:57:37 <tflink> other than that, it's accepted blockers
18:58:09 <tflink> jreznik: I'm inclined to throw out the 3 hour rule today since we're so close to go/no-go
18:58:15 * nirik nods.
18:58:18 <tflink> not that I want to sit here forever
18:58:35 <tflink> just realizing that anything not decided today is effectively rejecting an FE
18:58:55 <jreznik> tflink: I'm ok with that, just saying accepted blockers are now that urgent thing :)
18:59:10 <tflink> jreznik: yep, not arguing with you there
18:59:43 <tflink> are PM events enough to take that mate fix and selinux?
18:59:58 <Viking-Ice> ?
19:00:05 <nirik> what else is in the selinux update? just that fix?
19:00:24 <jreznik> you could argue suspend does not make sense on live, other pm events - no so sure
19:00:48 <rdieter> selinux-policy update is already stable
19:00:51 <adamw> selinux -54 is already stable.
19:00:55 <tflink> nirik:  I think so - it looks like re-adding stuff for consolekit
19:00:58 <adamw> we now have zero minutes.
19:01:06 <adamw> actually, negative 1!
19:01:15 <nirik> ok
19:01:42 <adamw> accepted blockers: we are feverishly working on 958426 and the unicode issues, there is a yum update for 924162 that needs testing
19:01:49 * jreznik would be ok with +1 as selinux-policy are in for brightness
19:01:55 <tflink> is this fixed in -54?
19:01:56 <adamw> i don't know what we're doing with 679486
19:02:23 <jreznik> adamw: ajax seems to be ok with workaround
19:02:57 <jreznik> [18:02] <ajax> i'm probably not going to have time to look into it today
19:02:57 <tflink> I see that we've moved on at adam's desire
19:02:58 <jreznik> [18:02] <ajax> the workaround seems reasonable, though i'd hope there's a better way
19:02:59 <tflink> fine
19:03:07 * adamw adds a comment
19:03:10 <tflink> #topic (924162) A software selection with dependency errors is allowed to proceed if the dependency check runs twice
19:03:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=924162
19:03:15 <tflink> #info Accepted Blocker, anaconda, NEW
19:04:48 <adamw> there's a yum build that should fix this now. we should test it if we can.
19:05:04 <kparal> it's not trivial to have access to a repo with broken deps
19:05:06 <Viking-Ice> adamw, word of confidence , "i think we can give it a shot. let's just hope it's okay."  ;)
19:05:17 <kparal> maybe we should set up one on our fedorapeople page to have some easy access to it?
19:05:18 <tflink> it's not that hard to do :)
19:05:27 <tflink> yeah, likely wise
19:05:41 <tflink> #info there is a build ready that should fix this
19:06:26 <adamw> Viking-Ice: yeah, i sound super confident there
19:06:41 <adamw> kparal: we may actually still have one left over from rhe, i'm not 100% sure
19:07:11 <tflink> -95 is current stable
19:07:20 <jreznik> adamw: see what ajax told me above - answer for the question from him, but yeah, more eyes...
19:07:27 <Viking-Ice> Change group install => group upgrade for installed groups. BZ 833087.  "You are not authorized to access bug #833087. " AAAARRRRGGGG
19:07:44 <tflink> this seems a bit risky to me - jumping from 95 to 99
19:07:58 <adamw> geppetto says the changes aren't actually that big
19:08:16 <Viking-Ice> yeah and we cant even look at what's being fracking fixed to assess the potential breakage from this
19:08:28 <Viking-Ice> fracking RH bugzilla junk
19:08:50 <adamw> Viking-Ice: if it's any consolation, if RHEL and Fedora had separate bug trackers, that would just be a link to a bug you couldn't open *in another bugtracker*.
19:09:01 <adamw> RHEL's always going to have private bugs, unfortunately.
19:09:27 * nirik nods. ;(
19:09:29 * adamw does some leaking
19:10:21 <Viking-Ice> we should be running our own fracking bugzilla instanc e
19:10:21 <adamw> looks like it basically makes 'yum groupinstall' act as a sort of 'yum groupupgrade' if some packages inthe group are already installed.
19:10:38 <adamw> Viking-Ice: like I said, if we were, you'd still have builds refer to bugs in the RHEL bugzilla. which you still couldn't access.
19:10:39 <nirik> this is a yum feature in f19 I thought.
19:11:10 <adamw> "Expected behavior yum groupinstall: installs all the remaining available mandatory packages in the group (even if 1 or more already there)."
19:11:14 <adamw> ""yum group update" does what you want, right?
19:11:14 <adamw> I'll add a pass through in so "group install" = "group update" for installed groups (as it does for packages on install => update)."
19:11:36 <adamw> that's the juice of the bug, basically. one of those rh-private bugs which REALLY doesn't need to be rh-private. /me applies Common Sense
19:12:27 <Viking-Ice> is there no chance to just pull in the fix we need?
19:12:30 * jreznik is trying to kick everyone who reports such bug as rhel private one
19:12:32 <nirik> so, test proposed fix? whats the question here?
19:12:36 <adamw> it's possible, but it'd require doing somewhat ugly stuff
19:12:49 <adamw> we'd have to hack up the yum package history quite a lot
19:13:29 <tflink> taking a bunch of yum changes this close to go/no-go makes me a bit nervous, though
19:13:31 <adamw> i was willing to let -99 slide as geppetto and clumens don't seem worried about it, but if the rest of you are worried, geppetto has said he can try to hack things up to do a 95.1 with the hcange we want
19:13:57 <Viking-Ice> tflink, it's simple really we slip and test the update properly
19:14:15 <tflink> which brings us back to your concern about that really being better, considering the existing builds
19:14:26 * nirik isn't clear on the changes there.
19:15:15 <jreznik> "hack" only patch does not sound good neither
19:15:42 <adamw> hi geppetto
19:15:44 <nirik> right. I'm willing to defer to geppetto / clumens since they know their code... whichever is the safer/better option.
19:15:47 <geppetto> adamw: hey
19:15:55 <tflink> yeah, same here
19:16:01 <adamw> so we're discussing whether we're okay pulling -99 to fix 924162 or if we'd really prefer to have a -95.1 with just the blocker fix
19:16:05 <tflink> I don't pretend to understand yum's codebase well enough to make this call
19:16:08 <Viking-Ice> defer if we pull this in we need to test this
19:16:17 <adamw> obviously we'd need to test
19:16:41 <adamw> so let's see the dates
19:17:17 <adamw> -91 went stable on 05-13; it was probably in TC1-3
19:17:52 <adamw> -94 went stable on 06-12; probably wasn't in any TC
19:18:10 <adamw> -95 went stable on 06-14; was probably in TC5-6 (TC4 was basically DOA)
19:18:29 <adamw> so we have two builds worth of testing of -95.
19:18:51 <adamw> tflink: i don't either, but on simple principle of least change it would seem clearly safer to take a 95.1 than a 99.
19:19:10 <adamw> i don't think any of the other changes between 95 and 99 is expected to bring anaconda any *benefits*, their only possible impact is to break stuff.
19:19:33 <tflink> as long as it doesn't screw other stuff up, I suppose
19:19:41 <tflink> the cherry-picking and rebuild
19:20:01 <Viking-Ice> it's not cherry picking is a hack being implemented to fix this right
19:20:51 <tflink> I didn't think the fix was so much of a hack
19:21:09 <drago01> Viking-Ice: he means cerry-pick the fixing commit
19:21:13 <tflink> the only place I'm seeing the word "hack" was talking about history munging
19:21:14 <drago01> cherry-pick
19:21:22 <adamw> Viking-Ice: by 'cherry picking' we mean 'plucking the fix for 924162 out and applying it against -95 and doing that build'
19:22:33 <Viking-Ice> that most definitely is the safest route to take but since we need to re-test this anyway we might just as well pull in the whole thing
19:22:45 <adamw> Viking-Ice: it's not just a question of re-testing
19:22:50 <adamw> it's a question of whether we *break stuff*
19:23:18 <adamw> if we re-test and find that stuff is broken that is better than not re-testing, but still a lot worse than *not breaking it*
19:23:29 <tflink> it sounds like there's an overall preference for taking 55.1 if that's not going to cause more problems
19:23:37 <Viking-Ice> yeah
19:23:40 <adamw> i dunno if i'd go that far, so far it's just me flapping my gums =)
19:23:48 <adamw> geppetto: how bothersome would it be to do a 95.1 ?
19:24:04 <adamw> dgilmore: nirik: would it require help on the releng side since 96-99 have been built?
19:24:17 <geppetto> adamw: The only real problem is dealing with the FC19 git to do the revert/rebuild.
19:24:22 <nirik> shouldn't... as long as 95.1 hasn't been
19:24:52 <nirik> geppetto: what changes are in 96-99? anything concerning, or all minor?
19:25:06 <geppetto> all minor bug fixes, a bunch are documentation too.
19:25:40 <nirik> if you and clumens are ok with 99, I'd personally be ok with it.
19:25:41 <geppetto> One patch adds a new command, but that code isn't run without the user doing something.
19:25:58 <adamw> clumens is basically washing his hands and saying he hasn't looked at the 95-99 changelog and has had enough of this bug
19:26:07 <nirik> if we do do that tho, perhaps we should do another tc today (if we can't do an rc yet) to get more testing.
19:26:08 <dgilmore> adamw: no, biggest hurdle is git
19:26:29 <tflink> or at least a smoke build
19:27:05 <jreznik> and in case of bad experience, we can try 95.1 (depends how much testing would be needed to be confident with 99)
19:27:31 <tflink> #info this should be fixed in the latest yum build (3.4.3-99) and the other changes should be minor and low risk
19:27:50 * nirik nods. lets just take 99. ;)
19:27:51 <adamw> in an ideal world i'd prefer to do a 95.1, i am okay with taking -99 and crossing all our limbs so long as if it all goes terribly wrong i get to say 'i told you so' and no-one fires me. =)
19:28:33 <adamw> new proposed FE bcl would like discussed: https://bugzilla.redhat.com/show_bug.cgi?id=974801 - he has a fix
19:28:37 <tflink> adamw: even though you already said you're OK with -99 inbug?
19:28:39 <Viking-Ice> but angry lynchmob can put you on fire
19:29:34 <tflink> anyhow, it sounds like the consensus is to take -99 and revert to -95.1 if problems arise
19:29:39 <jreznik> yep
19:29:40 <Viking-Ice> yup
19:29:53 <adamw> tflink: i can retcon that!
19:30:00 <adamw> anyhow, yep.
19:30:07 <adamw> patch for 974801 is https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-June/004736.html
19:30:19 <tflink> adamw: lets finish the accepted blockers first
19:30:28 <adamw> ah, sorry
19:31:21 <tflink> I assume nothing more on this?
19:31:30 <jreznik> move on
19:31:46 <jreznik> maybe info on the consensus
19:31:51 <tflink> #info will try -99 and revert to requesting -95.1 if problems arise
19:31:58 <tflink> #topic (958426) 19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB)
19:32:01 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=958426
19:32:04 <tflink> #info Accepted Blocker, LiveCD, NEW
19:33:18 <tflink> it sounds like work on this is ongoing
19:33:22 <adamw> in fact:
19:33:29 <adamw> 996147200 Jun 24 12:22 20130624-desktop-x86_64.iso
19:33:43 <adamw> that's a live I just built to test the unicode fixes - i pulled in latest spin-kickstarts and it looks like we're finally under
19:33:49 <adamw> will need to confirm with TC7/RC1
19:33:53 <jreznik> great
19:34:18 <tflink> #info work on this has been ongoing, latest unofficial build suggests that it may be fixed
19:35:18 <tflink> #info will need to verify with TC7/RC1
19:35:18 <jreznik> still I don't think we have to be byte strict now when we already broke CD size (not saying hundred megs, but a few megs...)
19:35:20 <adamw> jreznik: we should really settle that *outside* of a final release cycle, though.
19:35:20 <kparal> right
19:35:20 <tflink> anything else on this?
19:35:22 <jreznik> adamw: sure
19:35:29 <Viking-Ice> jreznik, Gnome desktop decides this
19:35:39 <Viking-Ice> next please
19:35:42 <dgilmore> jreznik: still kinda need to. if we say 1gb and someone only has 1gb usb stick we want it to fit
19:36:17 <tflink> dgilmore: true, but how big is a 1gb flash device? either way, a discussion for not-during-final-freeze :)
19:36:21 <tflink> #topic (679486) Liveinst doesn't start if hostname changes
19:36:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=679486
19:36:21 <tflink> #info Accepted Blocker, xorg-x11-xauth, ASSIGNED
19:36:28 <adamw> how long is a 1GB piece of string
19:36:44 <Viking-Ice> 3 round trips to the moon or so
19:36:46 <jreznik> "piece of string" - nice one :D
19:36:46 <dgilmore> tflink: right
19:37:13 <Viking-Ice> that one is still in needinfo
19:37:17 <ontossa> equal to 1000 1MB pieces of string
19:37:28 <jreznik> already sent it here but "<ajax> the workaround seems reasonable, though i'd hope there's a better way"
19:37:50 <jreznik> but he's not sure he will have time to take a look on it in reasonable timeframe for us
19:38:12 <bcl> adamw: it works by default, it just blows up if you change to raid and then back to None (or whatever that translates to)
19:38:13 <Viking-Ice> then we just have to wait until he does
19:38:39 <adamw> no, we should take kparal's workaround if we are not certain we'll get a 'better' fix in ~24hrs.
19:38:45 <adamw> assuming no-one else has a problem with the workaround.
19:38:51 <adamw> that's what my comment was asking.
19:39:00 <jreznik> and if kparal says it's working, I trust him
19:39:12 * adamw is all for neat and tidy fixes, but if we have something that fixes the main symptom right now, let's do it.
19:39:20 <kparal> jreznik: more testing welcome ;)
19:39:41 <kparal> I tested just GNOME Live
19:39:42 <jreznik> kparal: and good work on this one
19:40:02 <Viking-Ice> I'm fine with just adding a static hostname but more importantly "pam_xauth is just not working"
19:40:14 <tflink> #info we have a proposed workaround that appears to address the primary symptom of this bug
19:40:38 <jreznik> any volunteer to implement it?
19:40:40 <tflink> #info if there are no better solutions before the next TC/RC, we're likely to take that workaround for final
19:40:49 <bcl> adamw: but it didn't.
19:41:02 <bcl> it only fixed it from the terminal, which almost nobody will use.
19:41:13 <adamw> bcl: this is a different workaround.
19:41:22 <bcl> ah, ok.
19:41:30 <jreznik> bcl: https://bugzilla.redhat.com/show_bug.cgi?id=679486#c86
19:41:31 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=679486#c86
19:41:41 <adamw> just write out a /etc/hostname in live compose
19:41:54 <kparal> bcl: this one fixed it with .desktop launchers as well
19:42:12 <adamw> can you comment on that one in the bug?
19:42:55 <tflink> anything else on this bug?
19:43:30 * tflink assumes not
19:43:33 <adamw> if ajax and bcl sign off on the /etc/hostname workaround i'm prepared to go ahead and stick it in spin-kickstarts git ahead of the next compose.
19:43:58 <Viking-Ice> you can do it ;)
19:43:58 <bcl> oh, nice, I like that fix.
19:44:11 <tflink> #info waiting for ajax and bcl to comment on the workaround in https://bugzilla.redhat.com/show_bug.cgi?id=679486#c86
19:44:12 <jreznik> and ajax is ok too
19:44:37 <adamw> okay. let's go with it.
19:44:42 <jreznik> so we have ack - I can post my conversation with him to the bug
19:44:56 <adamw> yeah, please do.
19:45:14 <tflink> cool, anything else here?
19:45:18 <tflink> we
19:45:31 <tflink> we still have one last bug
19:45:31 <nirik> last bug? promise? ;)
19:45:31 <Viking-Ice> let's move to it
19:45:32 <tflink> nirik: in this meeting, sure
19:45:40 <tflink> overall, no. there will be more bugs :)
19:45:46 <Viking-Ice> nirik, probably that one and the one that adamw tried to hijack with
19:45:53 <tflink> #topic (974801) MDRaidError: invalid raid level descriptor なし
19:45:53 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=974801
19:45:53 <tflink> #info Proposed Freeze Exception, anaconda, POST
19:46:29 <tflink> for the record, なし translates to "None"
19:47:01 <tflink> for the record, if anyone cares etc.
19:47:02 <Viking-Ice> I cant see why we cant pull this in
19:47:10 <Viking-Ice> +1 FE from me
19:47:16 <tflink> but it sounds like bcl repro'd with english
19:47:32 <Viking-Ice> must have been non british english then
19:47:34 <tflink> or not. but either way, worth pulling in
19:47:35 <adamw> no, he repro'd with Japanese. it is only going to hit languages that have a translation for 'None' in the context of Raid levels.
19:47:50 <nirik> sure, +1 FE... the change looks simple.
19:47:51 <adamw> and you're only going to hit it if you try to explicitly set RAID level 'none' which is in fact the default.
19:48:05 <adamw> so it's really not incredibly serious...but then the fix isn't bad either
19:48:30 <bcl> No, with cz. it will fail with any that translated None. If they didn't it won't fail.
19:48:50 <bcl> yeah, that's why I'm for a FE not blocker.
19:49:18 <adamw> 679486 workaround pushed as bc4e104add2b06680c057735c2083559b1090ae5 .
19:49:23 <tflink> proposed #agreed 974801 - AcceptedFreezeException - This is a bit of a corner case with setting the RAID level when using languages which have translated "None" as a RAID level. A tested fix would be considered after freeze
19:49:27 <nirik> ack
19:49:29 <adamw> if bcl thinks this is safe, eh, +1 i guess. just don't bust anything.
19:49:29 <adamw> ack
19:49:30 <Viking-Ice> ack
19:49:39 <jreznik> ack
19:49:43 <tflink> #agreed 974801 - AcceptedFreezeException - This is a bit of a corner case with setting the RAID level when using languages which have translated "None" as a RAID level. A tested fix would be considered after freeze
19:50:01 <tflink> alright, time for open floor and endmeeting before any new blocker/fe bugs are proposed
19:50:06 <tflink> #topic Open Floor
19:50:15 <tflink> anything else that _has_ to be brought up now?
19:50:23 <tflink> keeping in mind that we're already 50 minutes over
19:50:36 <tflink> if not, /me sets the fuse
19:50:36 <adamw> just to note we have a planned fix for the unicode blockers
19:50:44 <adamw> i am currently uploading a live image for testing
19:50:53 <nirik> so possibly another tc later today? then rc ? or ?
19:51:01 <adamw> so if those who can reproduce 973019 and 973384 can stick around for a half hour until it's uploaded that'd be greatly appreciated
19:51:07 <Viking-Ice> can we have that plan in writing please with drawings
19:51:07 <adamw> nirik: RC today may be viable
19:51:09 <tflink> #info we have a planned fix for the unicode blockers - liveimage for testing will be sent out shortly
19:51:11 <nirik> cool.
19:51:15 <adamw> if the unicode fix works
19:51:23 * nirik crosses fingers.
19:51:32 <tflink> #info there will be a TC7/RC1 request today
19:51:33 <adamw> Viking-Ice: the plan is to revert pyparted 3.10 which appears to be the source of the misery
19:51:43 <adamw> Viking-Ice: and replace it with a 3.9 build with just the patches from 3.10 that we really need
19:51:44 * jreznik has to run, crosses fingers
19:52:23 <adamw> http://koji.fedoraproject.org/koji/taskinfo?taskID=5536817 is a scratch build of the new old pyparted if anyone wants to get a head start.
19:52:26 <Viking-Ice> adamw,  I see
19:52:33 <Viking-Ice> anything else ?
19:52:34 <adamw> live image ETA is 15 mins.
19:52:37 <bcl> I'll have a blivet/anaconda build later today.
19:52:56 <bcl> I'll bundle the pyparted in with that.
19:53:08 <adamw> can you actually separate them if it's not too much trouble?
19:53:15 <adamw> afaics there are no anaconda/blivet blockers, only FEW
19:53:17 <adamw> only FE
19:53:22 <jreznik> sounds promising, thanks guys! and really time to leave now
19:53:37 <adamw> so it would be nice to have the *option* to take pyparted separately from anaconda/blivet if the anaconda/blivet FE stuff turns out to bork something critical
19:54:07 <Viking-Ice> it's 19:51 here on top of the world and I'm still at $dayjob so I'm running as well
19:54:08 <adamw> so, ideally, one update with anaconda and python-blivet, one with pyparted
19:54:13 <adamw> cya viking, thanks for sticking around
19:54:17 <Viking-Ice> later...
19:54:52 <bcl> sure
19:55:57 <tflink> Thanks for coming everyone!
19:56:03 * tflink will send out minutes shortly
19:56:07 <tflink> #endmeeting