17:00:30 #startmeeting F24-blocker-review 17:00:30 Meeting started Mon Feb 29 17:00:30 2016 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:30 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:30 The meeting name has been set to 'f24-blocker-review' 17:00:30 #meetingname F24-blocker-review 17:00:30 #topic Roll Call 17:00:30 The meeting name has been set to 'f24-blocker-review' 17:00:37 * kparal is here 17:00:38 morning folks! time for some super fun blocker review 17:00:42 #chair kparal 17:00:42 Current chairs: adamw kparal 17:00:44 + 17:00:49 #chair RaphGro 17:00:49 Current chairs: RaphGro adamw kparal 17:01:04 i'm gonna leave roll call open for a few minutes since QA meeting only just wound up, give everyone a chance to take a break 17:01:36 * pwhalen is here 17:01:57 * kparal pokes pschindl 17:02:21 * pschindl is here too 17:02:52 * handsome_pirate waves 17:04:10 hi hi folks 17:04:41 hai adamw 17:06:52 everyone having a lovely monday morning? 17:07:15 * RaphGro bought a new graphics card in local shop. they sell crappy dead bricks! 17:07:24 ^ this morning 17:07:35 RaphGro: owch :( hope they take returns at least 17:07:43 * RaphGro hopes too 17:07:44 * handsome_pirate is a little under the weather 17:08:01 * handsome_pirate blames the lady friend; she was sick on Friday 17:08:09 RaphGro: ooph 17:08:32 alright, everyone got a coffee? 17:08:49 * handsome_pirate has orange soda 17:08:49 * RaphGro has headache cause of ICU patch 17:09:31 well, FeSCo discusses about getting rid of x86 anyways. 17:09:34 graphics card fell on you? 17:09:42 naa 17:10:14 .bug 1307633 17:10:15 RaphGro: Bug 1307633 icu: Many essential codes are missing in i386, such as almost all international latin encodings - https://bugzilla.redhat.com/1307633 17:10:52 fun stuff 17:10:57 alrighty, let's get rolling 17:10:57 indeed 17:11:00 kparal wants to get to the bar 17:11:02 #topic Introduction 17:11:03 Why are we here? 17:11:03 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 17:11:03 #info We'll be following the process outlined at: 17:11:05 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:11:06 #info The bugs up for review today are available at: 17:11:08 #link http://qa.fedoraproject.org/blockerbugs/current 17:11:10 #info The criteria for release blocking bugs can be found at: 17:11:12 #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria 17:11:14 #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria 17:11:16 #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria 17:11:35 adamw: where do you think I'm working from? 17:11:41 =) 17:11:46 that's the kind of work ethic i like to see 17:12:14 kparal: The best Fedora work gets done over alcohol 17:12:30 so we're just doing proposed blockers and accepted Alpha blockers this week, freeze is not till 2016-03-08 so we'll do FEs next week 17:12:40 we have: 17:13:07 #info 1 Proposed Blocker (Alpha), 3 Proposed Blockers (Beta), 3 Proposed Blockers (Final) 17:13:15 and: 17:13:17 #info 6 Accepted Blockers (Alpha) 17:13:46 it's worth noting several of the accepted Alpha blockers are new automatic blockers (i.e. they become Accepted without review being necessary) for all the big breakage from this week 17:13:52 so! moving right along to the proposed Alpha blocker... 17:14:01 #topic (1274451) sudo with graphical apps doesn't work on wayland 17:14:01 #link https://bugzilla.redhat.com/show_bug.cgi?id=1274451 17:14:01 #info Proposed Blocker, wayland, NEW 17:14:11 +1 17:14:30 well, wayland is a big feature 17:14:41 so this one's a slight guess, but at least as I understand the issue, it'll stop anaconda running on Workstation lives 17:14:47 I think the cleanest way here is to report a bug 'anaconda does not start under wayland' and block on that one 17:14:59 because I'm not sure we want to dictate how this gets fixed 17:15:04 hmm, true, as it could be fixed in other ways...yeah 17:15:10 yeah 17:15:26 and we should check it's actually true, as well (I was inferring it) 17:15:27 adamw: I'm thinking this bug needs to be more of a policy decision 17:15:50 adamw: I was hoping to get that discussion going, but it never seems to have materialized 17:16:03 handsome_pirate: yeah, that seems to be where this bug is going. 17:16:11 I quite dislike this problem (and it's not even clear they want to fix it), but we can't mandate they implement this, it does not break our criteria per say 17:16:15 ie, firmly decide yes or no to running gui applications as root 17:16:19 it breaks user habits, that's for sure 17:16:23 OK 17:16:49 when will wayland work? 17:17:01 RaphGro: it does work 17:17:03 so to avoid having to hold up the meeting or wait till next week to vote on an obvious blocker, how about we say we'll vote in principle on a new bug for 'anaconda doesn't run on Workstation live', assuming we test and that turns out to be the case 17:17:04 It already does 17:17:09 i'd be +1 to such a bug 17:17:16 kparal, ok. I keep with +1 17:17:21 adamw: +1 17:17:37 adamw: it might even be an automatic blocker. but +1 of course 17:17:59 one question though 17:18:02 sure 17:18:11 kparal: 42 17:18:26 is it acceptable solution when they set Live to use X11, and installed system to use Wayland? 17:18:52 * handsome_pirate thinks the goal is wayland live 17:18:57 can we decide we insist on Live running under the same graphics system as the installed system? 17:19:20 I'd be +1 to that 17:19:23 handsome_pirate: yes, but I can see somebody proposing this as a "temporary f24 measure" 17:19:41 kparal: I don't think we could refuse that under the blocker process 17:19:48 kparal: it would be more of a Change process thing 17:20:10 ok 17:20:13 i don't think *we* can insist that the Workstation live uses Wayland, but I think fesco could. 17:21:27 so either sudo has to start working under wayland, or anaconda needs to be modified, or workstation WG/Fesco needs to decide we keep the Live running on X11 17:21:28 so 17:21:40 those are the options 17:22:31 proposed #agreed 1274451 - drop blocker nomination, new bug is AcceptedBlocker in principle - we believe it makes most sense here to file a new bug for the specific "anaconda on Workstation live" case, if it is indeed broken. that new bug is accepted as a blocker in principle 17:22:41 oh, i forgot to find a secretary 17:22:46 anyone volunteer? 17:24:51 * adamw watches dust balls blow by 17:26:59 sorry, distracted by other other channels 17:27:05 ack 17:27:20 pschindl: wanna volunteer again, nudge nudge? :) 17:27:37 I'll do it 17:27:43 thanks 17:27:49 #info pschindl will secretarialize 17:27:56 ack/nack/patches on the proposal? 17:28:07 ack 17:28:35 ack 17:28:45 proposed #agreed 1274451 - drop blocker nomination, new bug is AcceptedBlocker in principle - we believe it makes most sense here to file a new bug for the specific "anaconda on Workstation live" case, if it is indeed broken. that new bug is accepted as a blocker in principle 17:28:46 grr 17:28:49 #agreed 1274451 - drop blocker nomination, new bug is AcceptedBlocker in principle - we believe it makes most sense here to file a new bug for the specific "anaconda on Workstation live" case, if it is indeed broken. that new bug is accepted as a blocker in principle 17:28:55 alrighty, onto the beta blockers 17:29:11 #topic (1294217) Background ignores stored orientation of images (layout is always put to landscape, even if image gets shown as portrait in an image viewer application) 17:29:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=1294217 17:29:11 #info Proposed Blocker, cinnamon, NEW 17:29:28 -1 17:29:38 commenter is right about not primary desktop 17:29:52 -1, per sgallagh, cinnamon is not a release blocking desktop. 17:29:55 propably freeze exception 17:29:57 -1 17:29:58 (this probably wouldn't be a blocker even in GNOME, but hey.) 17:30:13 not a release blocking desktop 17:30:20 well, it's hard to reproduce and seen on one box only 17:30:27 proposed #agreed 1294217 - RejectedBlocker - this is a Cinnamon bug, and Cinnamon is not a release blocking desktop. 17:30:29 * RaphGro = reporter 17:30:33 yep, figured that. :) 17:30:45 ack 17:30:48 ack 17:31:19 Cinnamon 17:31:23 #agreed 1294217 - RejectedBlocker - this is a Cinnamon bug, and Cinnamon is not a release blocking desktop. 17:31:25 but a patch / fix would be nice, anyways 17:31:40 we're not frozen yet, so it can still happen. :) 17:31:41 #topic (1312956) langpack split results in all locales being lost on update/upgrade 17:31:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1312956 17:31:42 #info Proposed Blocker, glibc, NEW 17:31:52 +1 17:31:58 this is the one i filed this morning for the langpack upgrade problem 17:32:06 same issues as with ICU, ICU is even more severe 17:32:17 b0rken i18n 17:32:25 +1 to blocker 17:32:31 sgallagh is working on it, though 17:34:01 one more vote? kparal? pschindl? 17:34:10 * adamw closes all kparal's other IRC channels 17:34:17 * kparal reading 17:34:32 +1 17:34:35 +1 17:35:09 what about the propoposal to add Suggests 17:35:14 shouldn't it be alpha blocker? 17:35:17 proposal * 17:35:32 pschindl: this is specifically for upgrades 17:35:39 ah, ok. 17:35:43 pschindl: we don't actually *know* yet what happens on a fresh install, because anaconda is broken 17:36:16 so we can't tell for sure what langpacks you wind up with on an install with the langpack stuff. i guess we could test with a pre-split netinst, but it'll be a separate bug if there is a problem 17:36:34 RaphGro: we're mostly concerned with deciding whether bugs are blockers, not how to fix them 17:36:38 separation of responsibilities! 17:36:46 k 17:37:06 * RaphGro calms down 17:37:15 the 'blocker committee''s jobs are a) decide if bugs are blockers b) make sure they get fixed on time...but specifically *not* c) decide how they should be fixed, except as it relates to b) 17:37:32 agreed 17:38:16 and when you need a precise definition for something, you go to adamw :) 17:38:17 proposed #agreed 1312956 - AcceptedBlocker - it's pretty clear from reports so far that this violates the specified criteria (upgraded systems do not meet the release criteria) 17:38:37 ack 17:38:45 ack 17:38:55 ack 17:38:59 kparal: if you need a precise *short* definition, on the other hand, go to anyone but adamw 17:38:59 :P 17:39:03 #agreed 1312956 - AcceptedBlocker - it's pretty clear from reports so far that this violates the specified criteria (upgraded systems do not meet the release criteria) 17:39:13 adamw: you would make a great lawyer 17:39:19 why, i oughta 17:39:22 #topic (1293055) Black screen after logout 17:39:22 #link https://bugzilla.redhat.com/show_bug.cgi?id=1293055 17:39:23 #info Proposed Blocker, sddm, NEW 17:39:24 lol 17:39:32 not htis again 17:39:50 oh, this is sddm 17:39:53 -0 17:39:56 still, sddm is releas blocking 17:40:11 as rex writes, it works but slow. 17:40:21 not tried yet with lxqt, though 17:40:24 Is it reproducable with kde? 17:40:35 RaphGro: bare metal or VM? 17:40:42 handsome_pirate: per comment #1 it is 17:40:42 what? kde? 17:40:53 "This is also reproducible when logout from a plasma5 session, using sddm here too. Now it's sddm to blame." 17:40:56 adamw: just saw that 17:41:04 +1 blocker 17:41:14 -+0 17:41:22 RaphGro: lxqt is not a release blocker; kde is 17:41:35 I know, we do not even have LXQt remix 17:41:35 well, it might be nice to have a bit more testing here 17:41:40 RaphGro: bare metal or VM? 17:41:43 be sure if it affects all uses 17:41:57 if logout is broken or extremely slow for all/most KDE installs, though, i'd be +1 17:42:02 kparal, vm with lxqt, no idea about kde 17:42:16 you should ask more competent kde users 17:42:45 we need more testing here first 17:42:51 ack 17:43:10 to try a default KDE install in a VM, once installer works 17:43:24 +1 for beta blocker 17:44:14 * RaphGro must leave shortly 17:44:29 proposed #agreed 1293055 - punt (delay decision) - this does smell blocker-y, but we want to have a few more people test with Plasma to be more sure of the breadth of impact before we vote on it 17:44:40 ack 17:44:52 ack 17:45:01 ack 17:45:08 meh 17:45:09 ack 17:47:42 * pwhalen is back, apologies 17:47:54 here, get a cookie 17:48:28 * handsome_pirate wonders what happened to adamw 17:48:30 sorry 17:48:34 #agreed 1293055 - punt (delay decision) - this does smell blocker-y, but we want to have a few more people test with Plasma to be more sure of the breadth of impact before we vote on it 17:48:41 * adamw was distracted by a shiny thing 17:49:03 alrighty, onto the final blockers 17:49:15 #topic (1311402) Icon for show applications is missing 17:49:16 #link https://bugzilla.redhat.com/show_bug.cgi?id=1311402 17:49:16 #info Proposed Blocker, gnome-shell, NEW 17:50:03 ongoing regressions with those icons 17:50:34 +1, seems clear enough. 17:50:50 +1 17:50:51 -0 17:51:09 +1 17:51:21 +1 17:51:52 proposed #agreed 1311402 - AcceptedBlocker (Final) - clearly violates "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." 17:52:33 ack 17:52:42 ack 17:52:59 ack 17:53:01 ack 17:53:24 #agreed 1311402 - AcceptedBlocker (Final) - clearly violates "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." 17:53:34 #topic (1310496) [abrt] eog: INT_cairo_region_is_empty(): eog killed by SIGSEGV 17:53:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=1310496 17:53:34 #info Proposed Blocker, gtk3, NEW 17:53:48 wtf? 17:53:49 * linuxmodder late 17:53:52 -1 17:54:19 please provide a readable bug title 17:54:27 you have to read the whole bug report 17:54:39 also, that's auto-generated by abrt, it's not in the user's control 17:55:01 "There's a patch in the upstream bug" 17:55:06 is eog installed with gnome by default? 17:55:06 (and it's quite useful to have the final bit of the traceback in the subject for abrt bugs in fact) 17:55:11 * handsome_pirate can't remember 17:55:13 handsome_pirate: i believe it still is, lemme double check 17:55:17 if so, +1 blocker 17:55:28 should I now suggest all my abrt reports? 17:55:42 yes, it's part of workstation-product 17:55:45 RaphGro: Only if they violate a release criteria 17:55:46 RaphGro: er...no? 17:55:54 RaphGro: this is a blocker because it's a crash on startup of a default installed app 17:55:55 Then +1 blocker 17:55:57 +1 then 17:56:04 aho k 17:56:07 +1 17:56:19 +1 17:56:21 i.e. the app doesn't work at all, and we have a criterion requiring that all apps installed by default in release-blocking package sets must at least somehow work 17:56:23 +1 17:56:27 +1 17:56:29 * RaphGro leaves 17:56:48 proposed #agreed 1310496 - AcceptedBlocker - eog crashing on start clearly violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." 17:56:52 ack 17:56:52 RaphGro: thanks for joining :) 17:56:53 ack 17:56:55 ack 17:56:58 always good to have more folks around 17:56:59 ack 17:57:04 #agreed 1310496 - AcceptedBlocker - eog crashing on start clearly violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." 17:57:14 #topic (1033778) installer considers encrypted Apple Core Storage volumes as resizeable 17:57:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=1033778 17:57:14 #info Proposed Blocker, python-blivet, NEW 17:57:20 alrighty, saved the controversial one for last :)( 17:57:25 .bug 1312675 adamw 17:57:26 heh 17:57:27 RaphGro: Bug 1312675 Please disable fatal warnings in dbus user session, dbus must guess about Qt5 applications - https://bugzilla.redhat.com/1312675 adamw 17:57:35 wanted to mention in open discussion 17:57:38 bye 17:57:46 RaphGro: OK, we'll look at it then 17:57:55 so this is the one we punted on last week on the basis that it clearly violates the criteria as written, but anaconda team were clearly unhappy with that 17:58:08 i have been talking to anaconda team about it this week on anaconda-devel-list 17:58:38 the thread is here: 17:58:38 https://www.redhat.com/archives/anaconda-devel-list/2016-February/msg00010.html 17:58:58 lemme give a quick summary of dlehman's position. 17:59:07 oh, my 17:59:39 fundamentally, anaconda can't tell the difference between a volume that contains an unknown filesystem and a volume that is not formatted 17:59:59 so what we really have here is a classic 'foot shooting' UI design conundrum 18:00:14 aye 18:00:28 if we disallow 'resize' of unknown volumes we might annoy some partition pokemon with a use case for resizing unformatted volumes 18:00:40 * handsome_pirate is hesitant to say a bug that causes data loss is not a blocker 18:01:00 if we allow it, we let people with partitions we don't know anything about shoot themselves in the foot if they try hard enough (by choosing to 'resize' an "unknown" partition) 18:01:18 I think the problem is that it's easy to assume that the resize operation is safe 18:01:21 handsome_pirate: well, on the one hand that, on the other hand resize is a fundamentally dangerous thing that we can't take out of the installer because people would complain. 18:01:50 so it should say "resizing an unknown partition, if you have some data on it, you'll probably lose it" 18:02:06 so ultimately dlehman's position is that we can choose to disallow this or not, but it really shouldn't be a blocker, and the criterion should be reworded somehoiw 18:02:09 kparal: aye 18:02:24 (or we can choose to throw some dumbass warning in there, yes) 18:02:32 lets reword it that 18:02:38 sorry, misclick 18:02:46 * kparal looking for that criterion 18:02:50 i had a plan 18:03:00 the cylons had a plan, too 18:03:02 basically, make it say any resize operation *for a known partition type* must blahblahblah 18:03:11 same wording, just restrict the coverage 18:03:17 hrm 18:03:43 i don't think i want to fight anaconda folks on this one, it doesn't seem clear cut enough to merit it 18:03:51 Is it possible to differentiate between 'unknown partition type' and 'unformatted partition'? 18:03:56 handsome_pirate: no. that's the problem. 18:04:06 there's no handy official "this is some kind of filesystem" identifier. 18:04:10 adamw: that rewording sounds ok to me 18:04:26 * handsome_pirate still doesn't like it 18:04:39 but I'd suggest anaconda folks to warn about resizing unknown partitions 18:04:42 to anaconda, a partition with nothing useful in it at all and a partition formatted with some filesystem anaconda knows nothing about look fundamentally the same. 18:04:47 kparal: +1 18:04:53 because the technical issues is not the problem here, the user assumptions are 18:05:03 well, isn't that always the case 18:05:10 heh 18:05:10 if we had perfect users everything would be so much easier 18:05:10 :P 18:05:22 adamw: would the anaconda folks add a dumbass alert? 18:05:23 or good UIs 18:05:34 note, the resize screen *does* say this: 18:05:42 handsome_pirate: possibly. that's kinda out of scope for deciding whether it's a blocker. 18:05:57 true 18:06:10 "There is also free space available in pre-existing file systems. While it's risky and we recommend you back up your data first, you can recover that free disk space and make it available for this installation below." 18:06:20 so we already *have* a warning, but no-one reads it, as y'all just proved. :P 18:06:31 heh 18:06:39 that does not really cover what we talked about 18:06:45 sure, i'm being flippant 18:06:51 adamw: It's been a whole two weeks since I've ssen anaconda! I don't have perfect memory :) 18:06:57 but a user assuming resize is safe is clearly a user not reading what we're telling them, where we tell them it's a fundamentally risky operation 18:07:16 i mean, resizes of *known* filesystems are nowhere close to 100% safe, which is why the criteria don't say they must work, only they must be correctly attempted 18:07:36 we can only be so strict about resizes, since it's a *fundamentally dangerous thing to do* 18:07:46 hrm 18:08:13 yeah, I think you're right 18:08:15 -1 blocker 18:08:26 I haven't seen a failed resize, but that's not important 18:08:35 plus, the criteria reword 18:08:35 but for the record: anaconda aren't saying they're not willing to make any changes. they're certainly open to adding a warning or only allowing 'resize' of known filesystems, i believe. but they do not believe the criteria should make this into a *blocker*. 18:08:55 * kparal nods 18:09:02 -1 and criteria rewording 18:09:04 i'm inclined to just go along with them as i don't think it's important enough to turn into a fight, so my vote is reword the criterion, -1 blocker 18:09:04 agreed, -1 blocker (but would like to see some dialog added) 18:09:33 if they can make it resize only known partitions, even better. 18:09:55 handsome_pirate: it's technically simple to do, it's just a question of whether that's what we want to do (i.e. do we want to piss off the partition pokemons) 18:09:55 anyhow 18:10:14 adamw: data safety > pissing off peoples, I think 18:10:28 but, maybe I've spent too much time as a sysadmin 18:11:06 proposed #agreed 1033778 - RejectedBlocker - anaconda team presented a reasonable argument that the release criteria should not be worded such that this issue is a blocker, so the criterion will be amended to only cover known filesystems, and this bug is rejected as a blocker. See bug comment for more details 18:11:28 ack 18:11:31 ack 18:12:09 ack 18:12:32 #agreed 1033778 - RejectedBlocker - anaconda team presented a reasonable argument that the release criteria should not be worded such that this issue is a blocker, so the criterion will be amended to only cover known filesystems, and this bug is rejected as a blocker. See bug comment for more details 18:12:35 okely dokely! 18:12:42 that's all the proposed blockers 18:12:59 woohoo 18:13:03 next we can take a look at any of the accepted Alpha blockers that might need any attention 18:13:46 * RaphGro is back 18:13:49 * kparal whispers 'boooriiing....' 18:14:22 looking at the list, we have several that are MODIFIED or ON_QA 18:14:31 and we have several new big ones that we know are being looked at 18:14:53 the only one that i guess i'm really worried about is: 18:14:54 #topic (1308771) Current Rawhide Workstation live image does not reach GDM due to mislabelled /run/systemd/inhibit and /run/user/1000 18:14:54 #link https://bugzilla.redhat.com/show_bug.cgi?id=1308771 18:14:54 #info Accepted Blocker, systemd, NEW 18:15:06 +1 18:15:17 RaphGro: we're onto accepted blocker review now 18:15:23 propably not GDM only 18:15:28 where we look at existing accepted blockers and check they're being addressed properly 18:15:34 so we're not voting, we're checking in 18:15:39 k 18:15:53 so i bisected this one down to a specific systemd commit which changed a bit how they do selinux init 18:16:08 however, systemd folks seem to be more or less saying 'we need someone selinux-y to figure out what's going on', best i can tell 18:16:37 there is discussion of this bug at https://github.com/systemd/systemd/pull/2508 also (which is the systemd PR for the change that broke things) 18:16:37 is anyone selinux-y looking at it? 18:16:43 /run is mounted as tmpfs, right? 18:16:50 i am not sure, but the lack of progress is concerning 18:17:05 my plan, unless anyone has a better idea, is just to email the selinux-y types I know and ask them to look at the issue 18:17:05 yes, it is 18:17:05 * RaphGro remembers something with tmpfs vs. selinux 18:17:18 /run is tmpfs 18:17:40 in past, they said "unsupported feature" 18:18:03 but it wasn't about /run 18:18:07 pestering selinux people sounds like a way to go 18:18:29 +1 18:18:38 okey dokey then 18:18:47 #info this is a major bug and the lack of progress is concerning 18:18:54 #action adamw to poke selinux folks to try and get some movement on this bug 18:19:08 did anyone have anything on any of the other accepted Alpha blockers? 18:21:07 * kparal shakes his head 18:21:11 well, selinux had a big update recently 18:21:28 maybe somehow related to .bug 1308771 18:21:49 RaphGro: doesn't seem that way, at least, you can switch the bug on and off across a single systemd commit 18:22:06 well, that's how systemd works 18:22:11 i suppose it's possible it would've worked with the systemd change with an older selinux, i haven't checked that, but it's definitely a systemd change which triggers the breakage 18:22:58 welp, we'll figure it out 18:22:59 onto open floor 18:23:04 #topic Open Floor 18:23:11 .bug 1312675 18:23:12 RaphGro: Bug 1312675 Please disable fatal warnings in dbus user session, dbus must guess about Qt5 applications - https://bugzilla.redhat.com/1312675 18:23:22 prevents new packages 18:23:31 or at least delays them 18:23:53 found via recent mass rebuild 18:24:16 I tend to propose as alpha freeze exception 18:24:24 as in, the test suites fail so you have to work around the bug in the spec or disable the tests? 18:24:32 yes 18:24:41 k 18:24:41 no idea how that influences production 18:24:46 that's pretty bad 18:25:02 but I have UAT there, so production may suffer also 18:25:09 production what? 18:25:19 daily usage of those applications * 18:25:23 oh, i see 18:25:31 they just crash 18:25:32 seems like one to keep an eye on for sure 18:26:11 maybe qt5 won performance improvements over qt4, so dbus did not care that all 18:26:35 but that's a shoot in blue sky 18:27:16 latest dbus update but those fatal warnings (whatever) been there longer 18:27:37 fixing every indiviual qt5 application is a PITA 18:29:03 ok, i think this wouldn't quite constitute a blocker at present but we should keep an eye on it and it may indeed need an FE if it doesn't get fixed before freeze 18:29:04 and: google chrome suffers too, linked upstream bug 18:29:20 well, the patch is doable 18:29:29 s|1|0| 18:29:35 #info 1312675 looks like it might be bad for package builds and possibly regular use of Qt 5 apps, we will keep an eye on it 18:29:42 ack 18:31:24 any other thoughts? 18:31:40 not right now 18:31:43