15:03:27 <adamw> #startmeeting Fedora QA meeting
15:03:27 <zodbot> Meeting started Mon Mar 11 15:03:27 2013 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:31 <adamw> #meetingname fedora-qa
15:03:31 <zodbot> The meeting name has been set to 'fedora-qa'
15:03:36 <adamw> #topic roll call
15:04:07 <adamw> note: rawhide has been displaying an adorable habit of hanging on me at random times, so i may drop out for a few minutes at some point. don't panic. hold memorial services if you like.
15:04:13 * satellit listening
15:04:15 * pwhalen waves
15:04:26 <brunowolff> I can't stay the whole time, but I was interested in knowing if gnome not working with software rendering is a blocker issue?
15:04:36 * mkrizek is here
15:05:00 <brunowolff> I have issues with gdm and gnome3 because software rendering is needed and is broken.
15:05:05 * tflink is here
15:05:30 * kparal waves
15:06:03 <halfline> yea sounds like a blocker issue
15:06:17 <adamw> if llvmpipe is busted, yeah, raise the panic flag on that one
15:06:57 <brunowolff> I have a couple of bugs filed, but will request them as blockers for eval at the next blocker meeting.
15:07:20 <Martix_> Martix is here
15:07:48 * nirik is lurking, has a few items for open floor
15:08:42 <adamw> brunowolff: yup, we need some proposed blockers anyhow :)
15:08:47 <adamw> #chair tflink kparal
15:08:47 <zodbot> Current chairs: adamw kparal tflink
15:10:42 <adamw> okely dokely
15:10:47 <adamw> i guess viking will show up soon as per usual
15:10:54 <adamw> #topic previous meeting follow-up
15:11:39 <adamw> #info "adamw to push the blocker meeting changes live this week" - this was done, see https://lists.fedoraproject.org/pipermail/test/2013-March/114175.html
15:11:55 <adamw> so assuming we actually hold the first meeting this week, it should follow the new process
15:12:27 * pschindl is late but here (time shifting is bad thing)
15:12:31 <adamw> #info blocker review meeting on wednesday will be in #fedora-blocker-review, update your...xchat bookmarks?
15:12:37 <nirik> shall I kill off the bugzappers channel and or forward it to the new channel?
15:12:43 <adamw> pschindl: daylight savings should die a horrible death.
15:13:03 <adamw> nirik: oh right, i forgot to reply to that. what does 'killing' constitute exactly?
15:13:08 <adamw> could we get it back?
15:13:23 <nirik> well, I guess setting it to ban everyone. ;)
15:13:40 <nirik> yeah, anything that is #fedora* can be gotten back from freenode.
15:13:59 <nirik> we could just change the topic and leave it to sit.
15:14:17 <nirik> or redirect everyone who tries to join it to qa or something.
15:14:44 <adamw> redirect sounds decent for now, i guess?
15:14:49 * adamw doesn't really have a strong opinion
15:14:56 <nirik> ok, to #fedora-qa ?
15:15:06 <tflink> yeah, redirect sounds like a good option
15:15:24 <tflink> #fedora-qa makes the most sense to me
15:15:57 * nirik nods.
15:16:10 <adamw> any other opinions?
15:16:20 <kparal> +1
15:16:38 <tflink> what are we going to call the new channel?
15:16:50 <tflink> #fedora-blockerreview?
15:16:52 <adamw> see above.
15:17:11 <adamw> it was right there in the #info :)
15:17:21 <tflink> but that would require reading ...
15:17:34 * jreznik is here
15:17:59 <adamw> tflink: it's just work work work all the time, huh
15:18:09 <adamw> okay, nirik, make it so
15:18:17 <adamw> #info nirik will set #fedora-bugzappers to redirect to #fedora-qa for now
15:18:35 <nirik> can do
15:18:55 <adamw> #info "viking-ice or adamw to file a trac ticket for the smoke-test-for-spins idea" - did that: https://fedorahosted.org/fedora-qa/ticket/363
15:19:45 <adamw> #info "adamw to propose RATS/TC1 dates on the list" - did that too! I'm on a roll. https://lists.fedoraproject.org/pipermail/test/2013-March/114176.html
15:20:02 <adamw> i put a topic on the agenda to discuss those dates later, so let's move on for now
15:20:17 <adamw> "tflink to announce first blocker meeting for wednesday, and get blocker bug tracker app ready"
15:20:28 <adamw> tflink: the meeting was cancelled, but the blocker app is ready now, right>
15:20:50 <tflink> kind of done - we didn't have the meeting but the app is working with F19 stuff now
15:21:12 <adamw> roger
15:21:34 <adamw> #info "tflink to announce first blocker meeting for wednesday, and get blocker bug tracker app ready" - meeting was cancelled due to lack of bugs, but the app is ready
15:21:40 <tflink> still working out hosting details in order to support the blocker proposal stuff w/o using self-signed certs
15:21:59 <adamw> #info tflink is working on hosting details for the blocker proposal web page
15:23:02 <adamw> "jreznik to pencil in QA changes as discussed" - jreznik?
15:24:08 <jreznik> adamw: draft schedule changes online, need review, as adamw said - let's discuss it in the meeting
15:24:19 <jreznik> http://fedorapeople.org/groups/schedule/f-19/f-19-quality-tasks.html
15:24:20 <adamw> roger
15:24:33 <adamw> #info "jreznik to pencil in QA changes as discussed" - this was done, we will finalize the changes during the meeting
15:25:13 <adamw> #info "adamw to draft up changes to the test day process docs to accommodate test days being on any day, test day co-ordinator to ensure they're balanced out" - this was put into 'production' immediately as it turned out to be a small change, https://lists.fedoraproject.org/pipermail/test/2013-March/114194.html
15:26:17 <adamw> alrighty
15:26:23 <adamw> #topic Fedora 19 schedule
15:26:40 <adamw> so i drafted up a schedule for the image composes for f19, following the f17/f18 model closely: https://lists.fedoraproject.org/pipermail/test/2013-March/114176.html
15:26:47 <adamw> it didn't get much feedback. anyone have any notes?
15:27:35 <jreznik> it's now live in schedule (more a draft, not commited yet)
15:27:46 <tflink> nothing specific but earlier is probably better for TCs, I think
15:28:03 <jreznik> and was harder to do than I thought as half of the schedule depends on release candidates...
15:28:18 <jreznik> tflink: that's what rats is for
15:28:44 <adamw> tflink: the 'do TCs early' thing was pretty much worked into the f17 schedule
15:29:04 <jreznik> and after talking to guys pre-feature freeze I think we should take a look on rats more closely and do it really for rawhide, not after branch (early TCs could serve there)
15:29:13 <adamw> this schedule gives us 22 days between tc1 and go/no-go for each milestone
15:29:39 <jreznik> adamw: for your proposed dates, I've moved go/no-gos again to thursday (so +1 day)
15:29:41 <adamw> jreznik: rats would have been of limited use this cycle because of all the changes being made to anaconda
15:29:48 <adamw> it would likely have failed a lot and not told us much
15:29:52 <adamw> jreznik: ah right, good catch
15:30:11 <tflink> jreznik: I don't see a whole lot of difference between RATS and a TC other than the name, though
15:30:13 <jreznik> adamw: for f18 it wasn't very usable, for f19 it should be better but probably the must for f20
15:30:35 <tflink> either way, I'm not particular on what we call it as long as there's stuff to test
15:30:45 <jreznik> tflink: adamw thinks about rats after branching as a quick smoke test (so how do we want to produce it?)
15:30:53 <jreznik> tflink: I agree, earlier, better
15:31:03 <tflink> smoke/rats/tc ... they all work
15:31:11 <jreznik> that's why I'm thinking about moving rats again pre-brach for f20
15:31:26 <adamw> jreznik: even for f19 - they've been doing their test builds based on f18 again, and it's been frequently broken
15:32:16 <jreznik> adamw: well, we have been using f19 build for anaconda usability lab, wasn't perfect but it gives you an overview and helps with development of installer related features
15:32:37 <jreznik> at least once a time try to "stabilize" something and give it to QA/devels
15:32:56 <adamw> sure. but running rats on it wouldn't have meant much. rats per se is just a single 'does it install' test.
15:33:40 <jreznik> but at least you would have somethin to try "does it install"
15:33:51 <jreznik> let's get back to f19 now :)
15:34:10 <tflink> we could just build smoke images as soon as the branch is complete
15:34:12 <adamw> yeah
15:34:20 <tflink> should be functionally the same
15:34:35 <jreznik> tflink: that's the idea for f19, to build smoke images this week
15:35:39 <jreznik> and branching is tomorrow, adamw proposed Thursday
15:35:47 <jreznik> as it hopefully will be completed
15:36:07 <jreznik> this time there's more time between branch and alpha change deadline
15:36:29 <jreznik> so there's some "buffer" but I agree with as early as possible one
15:39:01 <adamw> doesn't sound like anyone's unhappy with the proposed schedule? I guess we can just go with it
15:39:05 <jreznik> anything else to add to the schedule? /me would like to add Test Days for F19 as Ambassadors asked for a task connected to it
15:40:41 <adamw> what do you mean exactly? add each individual test day there? or just 'test days' as a block task lasting X days?
15:41:24 <jreznik> adamw: the second
15:41:30 <adamw> seems fine
15:41:56 <jreznik> sesivany asked for it, so they can remind ambassadors to do more marketing for Test Days
15:42:33 <jreznik> looking on older releases, Test Days are scheduled right after Feature/Branch Freeze to GA
15:42:55 <jreznik> not sure how much sense does it make right before GA, but ok for me :)
15:42:55 <adamw> basically, yeah
15:42:58 <adamw> "between the Alpha and GA milestones of a Fedora release"
15:43:14 <adamw> well what happens usually is if you pick that spot, you get a good date once the schedule delays shake out ;)
15:43:20 <jreznik> well, it's more between Feature/Branch Freeeze and GA
15:43:30 <adamw> yeah, it doesn't mean 'alpha release'
15:43:55 <jreznik> this is just clearer definition as Alpha is quite generic term
15:44:04 <adamw> #action jreznik to ink in the proposed image schedule, and add a Test Day entry
15:44:10 <adamw> yeah, i could edit that on the wiki.
15:44:18 <jreznik> thanks
15:44:45 * j_dulaney apologizes for tardiness
15:44:56 * j_dulaney is on spring break, and just woke up
15:45:28 * adamw hopes j_dulaney is surrounded by bottles
15:45:53 <adamw> #topic Test Days
15:46:04 <adamw> so this is left over from last week's test day topic - a couple of things there that we forgot to discuss
15:46:20 <adamw> i see someone's added "KDE Test Day - this Thursday, need build F19 KDE Live images, currently failed 03/10 - ask dgilmore?"
15:46:39 <adamw> i usually handle building GNOME test day images myself, we could do the same for KDE - building live images isn't that hard
15:47:05 <nirik> the kde images are currently failing due to mysql fallout
15:47:21 <j_dulaney> adamw:  Actually ...
15:47:26 <j_dulaney> adamw:  Home made meade
15:47:58 <adamw> outstanding. it's not a dulaney spring break without home-made mead.
15:48:07 * satellit anaconda fails to show spokes from liveinst in nightlys FYI
15:48:20 <jreznik> nirik: I see rdieter commited one mariadb deps fix today
15:48:27 <j_dulaney> nirik:  What sort of mysql explosion is going on?
15:48:35 <nirik> jreznik: I don't think it worked. ;)
15:48:43 <nirik> j_dulaney: the mariadb replacement stuff.
15:48:48 <jreznik> rdieter: ^^^?
15:48:50 <nirik> discussion is ongoing on devel list
15:48:50 <j_dulaney> nirik:  Ah
15:49:03 * nirik doesn't think we will solve it here, just informational.
15:49:06 * j_dulaney looks
15:49:09 <jreznik> ok
15:51:53 * nirik guesses adamw's machine locked up. :)
15:51:56 <adamw> so it's mkrizek who wanted to discuss this stuff, but he's not around
15:51:59 <adamw> no, i'm just reading /.
15:52:08 <adamw> so i guess we can just make some notes and move on
15:52:18 <adamw> #info we'll need to do some special care and feeding of a KDE test day image for this week
15:53:10 <adamw> let's punt the other two things to next week, assuming martix will be here
15:53:23 <adamw> er, martix and mkrizek are the same person, for anyone who didn't get that.
15:53:39 <adamw> #info the rest of the test day topic is tabled for next week (or whenever martix is around)
15:53:41 <kparal> no they are not :)
15:53:53 <adamw> PEOPLE NEED TO TELL ME THESE THINGS
15:54:06 <adamw> where did I get that idea from? sigh.
15:54:09 <kparal> martix == mholec
15:54:10 <adamw> #undo
15:54:10 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x269fff90>
15:54:14 <adamw> d'oh.
15:54:26 <adamw> no, wait, that one was right.
15:54:31 <j_dulaney> LOL
15:54:32 <adamw> you know what, I'm going to bed
15:54:36 <adamw> #info the rest of the test day topic is tabled for next week (or whenever martix is around)
15:54:44 * j_dulaney wonders who is the more hung over
15:54:50 <adamw> disregard all mentions of mkrizek above, because adamw is an idiot monkey.
15:55:00 <pingou> info?
15:55:13 <adamw> #info disregard all mentions of mkrizek above, because adamw is an idiot monkey.
15:55:21 <adamw> there, would you like me to put it on a billboard? :)
15:55:21 <pingou> ^^
15:55:28 <pingou> yes, please :)
15:55:35 * adamw calls clear channel
15:55:41 <nirik> you must pay to have an add in the new york times. ;)
15:55:42 * pingou goes back to his corner
15:55:49 * adamw golf claps
15:56:08 <adamw> alrighty, moving on, adam wilson has a proposal to edit the release critera...:P
15:56:11 <adamw> #topic Criteria re-design
15:57:10 <adamw> so I wrote a giant proposal for editing the release criteria. https://lists.fedoraproject.org/pipermail/test/2013-March/114198.html
15:57:43 * j_dulaney is +1, btw
15:57:44 <adamw> i was expecting at least one person to advocate burning me at the stake for it, but not so far.
15:57:51 <adamw> we're a bit short on time now, but any quick thoughts?
15:58:00 <j_dulaney> Sorry for not posting on the list
15:58:15 * nirik thought it looked ok. We can always adjust as we go if needed.
15:58:47 <tflink> I'm +1 on the general idea but I shudder at the thought of using the new layout for blocker review meetings
15:58:55 <adamw> tflink: how do you mean?
15:59:02 <tflink> adamw: finding
15:59:08 <tflink> adamw: finding criteria
15:59:14 * j_dulaney is +1 adding numbers
15:59:20 <kparal> it's true that the hidden text can't be searched through
15:59:29 <kparal> if that's what you mean
15:59:46 <tflink> kparal: that's pretty much it, yeah
15:59:46 <pwhalen> Had a couple of release criteria related questions. For ARM to move to PA, we need to start following the guidelines, which for the most part we do. We do however have a challenge when it comes to the release blocking desktops and installer related criteria.
15:59:49 <j_dulaney> Even if they do change between releases, numbers still makes reference easier
16:00:02 <Martix> I'm back
16:00:19 <pwhalen> could the release blocking desktops be defined for the architecture? ie GNOME and KDE for x86. XFCE for arm?
16:00:33 <tflink> numbers haven't really been helpful in the past, though
16:00:44 * j_dulaney thought they were
16:01:03 <kparal> numbers change in time
16:01:05 * tflink couldn't tell you what alpha criterion 7 vs final #7 are
16:01:21 <adamw> tflink: i figured the reliable 'names' for criteria and the clearer text would make it easier, but maybe not...
16:01:30 <j_dulaney> Not for memorizing, but for in meeting use
16:01:34 <j_dulaney> It saves typing
16:01:37 <adamw> tflink: i would like if we could have an 'expand all' link but i'm not sure we can with this particular wiki thing
16:01:40 <jreznik> pwhalen: so you mean pre-PA, or even post-PA for the desktops stuff?
16:01:55 <adamw> yeah, the numbers are pretty much useless the way we currently do it
16:02:02 <jreznik> (and we could expect different primary desktops based on arch)
16:02:02 <nirik> pwhalen: if arm wants Xfce as release blocking, we might also want to try and add it to primary...
16:02:04 <adamw> pwhalen: in theory they can be, sure.
16:02:04 <tflink> I don't remember the last time we referenced criterion numbers in meeting
16:02:17 <j_dulaney> pwhalen:  That's vagualy a FESCo-ish question, to
16:02:21 <j_dulaney> s/to/too
16:02:25 <adamw> pwhalen: one does not simply 'define' release blocking desktops, however ;)
16:02:31 <pwhalen> jreznik, even post. The hardware is limited and GNOME/KDE will not work. Most systems lack a desktop altogether
16:02:33 <tflink> it adds a layer of indirection that I'm not a huge fan of - makes things more confusing
16:02:37 * nirik realizes his reply didn't fully make sense there.
16:02:38 <adamw> as j_dulaney says, it's kind of a project wide thing, not just something QA Decides
16:02:58 <adamw> you'd probably want to make it an issue in the ARM-as-primary process
16:03:06 <j_dulaney> Alright,
16:03:15 * j_dulaney withdraws desire for criteria numbers
16:03:31 <tflink> adamw: yeah, I don't have a better solution with the constraint of staying inside the wiki - we'll manage :)
16:04:01 <adamw> tflink: well if you can think of an alternative design that keeps the metadata separate from the simplified criteria but easily accessible and clearly linked, i'm all ears
16:04:16 <jreznik> pwhalen: btw about being close to the current PA - would you like to have my help too as a program manager? (OT here, we can discuss seperately)
16:04:19 <adamw> there's probably some kind of way to do it with footers and *s or something
16:04:28 <pwhalen> adamw, alright, that makes sense. For the installer related criteria, since we do not have an installer, those items wouldn't apply. Is the wording sufficient as is?
16:04:53 <pwhalen> jreznik, that would be greatly appreciated
16:04:59 <tflink> adamw: like I said, I don't have a better idea inside the wiki and am +1 in general - just realizing that it'll be an adjustment
16:05:05 <adamw> pwhalen: more or less. i think rather than tweak individual criteria wording it's an 'overall flow of the criteria' question. i'm trying to keep it in mind as I go, but we only really need to fully deal with it once ARM actually *is* a primary arch
16:05:16 <adamw> and trying to account for it before ARM is a primary arch is putting the horse before the cart to a degree
16:05:35 <adamw> i'm trying to bear in mind both 'ARM is probably going to be a primary arch at some point' and 'ARM is not in fact currently a primary arch'
16:05:45 <adamw> and also consider the case of the EC2 image etc.
16:06:07 <pwhalen> adamw, understood
16:06:13 <adamw> but in general, read the criteria as meaning 'when the installer is present it must fulfil conditions X, Y and Z' than 'there must always be an installer'.
16:06:39 <j_dulaney> +1
16:06:45 <pwhalen> much more arm friendly. sounds good on both concerns, thanks
16:07:08 <j_dulaney> pwhalen:  I didn't see anything major with the arm-specific criteria you'd come up wiht
16:07:35 * j_dulaney will poke at that list today for you
16:08:07 <pwhalen> just those two items so far, will forward to the arm list after the meeting for discussion
16:08:15 <j_dulaney> pwhalen:  Anyway, a few things occur to me that I'd like to discuss after the meeting, maybe in #fedora-arm
16:08:31 <pwhalen> j_dulaney, sure
16:09:07 <adamw> okay, we're a bit over time, thanks for the feedback
16:09:13 <adamw> i'll keep working on the proposal
16:09:16 <adamw> #topic open floor
16:09:21 <adamw> anything for open floor?
16:09:34 <nirik> I had two quick items.
16:10:02 <nirik> item the first: I have drafted a replacement for our Rawhide wiki page. Feedback welcome. I will probibly move it in place soon if I don't hear any complaints.
16:10:04 <adamw> fire away, fire away
16:10:13 <nirik> https://fedoraproject.org/wiki/User:Kevin/RawhideDraft
16:10:16 <adamw> (TIGH TAY NEEEEEE UM)
16:10:30 <adamw> did you send it out anywhere for comments?
16:10:35 <kparal> was that a canadian war cry?
16:10:40 <nirik> yes, I mentioned it on the test list and devel lists.
16:10:43 <j_dulaney> adamw:  It's on the list
16:10:50 <adamw> kparal: no, it was that song that was all over everywhere
16:10:51 <j_dulaney> Long thread
16:11:04 <adamw> shows you how much mail I read over the weekend...
16:11:07 <adamw> looks fine at a once-over.
16:11:17 <nirik> I might also do another rework for the branched page soon.
16:11:23 <nirik> item the second:
16:11:54 <nirik> What would folks think about a rawhide blocker bug? At a first start it could block bugs that prevent rawhide compose, but we could also add further critera for it.
16:11:57 * j_dulaney thinks it's an improvement, and is +1 for it
16:12:19 <adamw> i prefer calling them 'tracker bugs', as the term 'blocker' is a bit overloaded
16:12:25 <nirik> yeah, sorry.
16:12:36 <adamw> a tracker for issues that are breaking rawhide completely seems like a good thing to have
16:12:39 <j_dulaney> nirik:  BTW, apologies for never getting back to you on those nightlies, they never quite booted
16:12:42 <nirik> I can send a proposal out on that too, but thought I would see if folks thought it was dead in the water first, etc.
16:12:56 * jreznik is going to read it
16:13:02 <adamw> naw, i like it. it shouldn't have any kind of 'proposal/acceptance' process like the release blocker trackers though.
16:13:02 <jreznik> (missed before)
16:13:10 <tflink> would it involve reviewing the rawhide "blockers"?
16:13:24 <nirik> adamw: yeah, but it shouldn't allow anything to be added.
16:13:24 <jreznik> tflink: could be your app used for it then?
16:13:26 <adamw> it should just be for rawhide gardeners to follow and deal with directly.
16:13:32 <j_dulaney> nirik:  It should be anyone can propose against it
16:13:37 <adamw> nirik: how would you implement that?
16:13:45 <kparal> I'd love to see rawhide tracker bug that would list most problematic bugs (like systemd doesn't boot or gdm doesn't start). this way I could quickly find a relevant bug and maybe even a workaround if rawhide didn't work for me
16:14:00 <tflink> jreznik: probably, but it would likely require some code changes
16:14:03 <kparal> s/systemd/system
16:14:21 <nirik> adamw: I'd list critera that should be used to add things to it... if something doesn't match that I'd remove the bug and tell the person who added it to not do that. ;)
16:14:26 * j_dulaney doesn't think that there should be a review process for rawhide bugs, though
16:14:29 <adamw> that sounds fine.
16:14:30 <nirik> kparal: yeah, that was my thought too.
16:14:39 <j_dulaney> Not unless they are going to hit the next release
16:14:48 <nirik> kparal: give better visibility for rawhide users to find breakage quickly.
16:15:05 * kparal thinks it's a great idea
16:15:05 <adamw> obviously it's kind of creating the position of 'head rawhide herder', though, which you'd probably want to quantify in some way for raptor proofing purposes...
16:15:11 <adamw> or have a group of 'rawhide herders', or whatever.
16:15:16 <nirik> yeah.
16:15:39 <nirik> I'll whip up a proposal to the list for discussion/refinement
16:15:45 <adamw> but yeah, keep it light and informal, no big meetings or lists of criteria or any of that nonsense ;)
16:15:56 <j_dulaney> +1
16:15:58 <nirik> right. I completely agree.
16:17:09 * jreznik thinks about being such rawhide herder, it could push him to use rawhide on daily basis
16:17:19 <adamw> you too can enjoy random kernel hangs!
16:17:26 <adamw> nirik: was there something else or was that both your topics?
16:17:34 <nirik> thats it from me. :)
16:17:39 * nirik is not seeing kernel hangs here.
16:18:28 <adamw> #info nirik has a Rawhide wiki page proposal out for discussion - https://lists.fedoraproject.org/pipermail/devel/2013-March/179597.html
16:18:35 <jreznik> wow, http://lwn.net/1998/0820/rawhide.html :)
16:18:39 <adamw> #agreed we like nirik's idea of a tracker bug for Rawhide showstoppers
16:18:47 <nirik> yeah. ;) more history welcome if anyone remembers it.
16:19:13 <adamw> alrighty, let's wind this puppy up
16:19:16 * adamw sets fuse for 2 minutes
16:19:16 <Martix> https://lwn.net/Articles/506831/
16:19:30 <Martix> jreznik: regarding mariadb KDE fix, will it hit image composes tomorrow?
16:20:04 <nirik> Martix: there's not a fix yet.
16:20:08 <nirik> hopefully soon
16:20:24 <Martix> [16:48] <jreznik> nirik: I see rdieter commited one mariadb deps fix today
16:20:37 <nirik> it didn't help/work
16:20:39 <nirik> http://kojipkgs.fedoraproject.org//work/tasks/4248/5104248/livecd.log
16:20:53 <j_dulaney> jreznik or nirik:  When there is something testable, could you drop an email on the test list?
16:20:56 <j_dulaney> For KDE, that is
16:21:05 * j_dulaney will happily test
16:21:17 <rdieter> the only "fix" I applied was changing one place that previously: Requires: mysql-server to Requires: mariadb-server
16:21:24 <rdieter> I highly suspect it won't help
16:21:35 <nirik> rdieter: it didn't. see above. (that was after your commit)
16:21:59 <rdieter> I suspect something requires libmysqlclient, and MySQL-libs wins
16:22:15 <jreznik> rdieter: could you take a look on that so guys could prepare the image for Thursday (also a reminder for the whole KDE SIG ;-)
16:22:18 <rdieter> (probably due to the last fallback of shortest name)
16:23:02 <rdieter> hence, my query onlist to simply exclude MySQL from composing, but that may be overkill
16:23:16 <rdieter> unless someone else has a better idea
16:23:36 * nirik wishes the mariadb maintainers would actually chime up
16:23:44 <adamw> it'd be easy enough just to exclude mysql from a kickstart to build a test day image. it's like one line.
16:23:57 <adamw> well, it might be.
16:24:03 <rdieter> adamw: how?  repo ... --exclude ?
16:24:19 * rdieter already tried naive: -MySQL*  in pkg list
16:24:23 <adamw> you can try just -mysql-libs (or whatever), but i guess dependencies can override that
16:24:23 <adamw> ah
16:24:38 <adamw> yeah, it may be possible to exclude it from the repo definition then
16:25:49 <rdieter> I can't think of any sane way to do this as long as mariadb and MySQL aren't parallel-installable
16:26:04 <adamw> alright. well, i think we've identified the problem anyway
16:26:21 <brunowolff> I think things have changed so that when you use - the package is virtually removed from the repo so that other dependencies can't bring it in. The compose will fail instead.
16:26:51 <rdieter> brunowolff: that does not seem to be the case
16:26:57 <adamw> i think we can work on fixing it outside the meeting
16:27:06 <adamw> thanks for coming, folks - further discussion to #fedora-qa or #fedora-kde i guess
16:27:09 <adamw> #endmeeting