14:00:48 <tflink> #startmeeting fedora-qadevel
14:00:48 <zodbot> Meeting started Mon May 16 14:00:48 2016 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:48 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:00:53 <tflink> #meetingname fedora-qadevel
14:00:53 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:01:01 <tflink> #topic roll call
14:01:15 * kparal ois here
14:01:20 * mkrizek is here
14:02:18 * jskladan is here
14:02:19 * garretraziel is here
14:02:42 <tflink> let's get this party started, then
14:02:59 <linuxmodder> .hello linuxmodder
14:03:00 <zodbot> linuxmodder: linuxmodder 'Corey W Sheldon' <sheldon.corey@openmailbox.org>
14:03:00 <tflink> #chair kparal mkolman garretraziel jskladan
14:03:00 <zodbot> Current chairs: garretraziel jskladan kparal mkolman tflink
14:03:09 <linuxmodder> (/me has to  bounce in like  15 mins)
14:03:30 <tflink> #topic Announcements and Information
14:03:33 <tflink> linuxmodder: no worries
14:04:14 <tflink> #info F24 Beta Freeze is over
14:04:25 <tflink> other than that, nothing was listed that I see
14:04:36 <tflink> other comments, questions, items to add?
14:05:24 <garretraziel> nothing here
14:05:32 <linuxmodder> was noticing on Server beta  64  xorg-x11-drv-libinput  was NOT pulled in when  using  lxde or  xfce as a minimal gui
14:05:57 <linuxmodder> other than that  still working mktg and docs on the  final release guides and docs
14:06:02 <coremodule> .hello coremodule
14:06:03 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
14:06:03 <coremodule> .back
14:06:26 <jskladan> nope
14:06:39 <kparal> linuxmodder: this is a qa-devel meeting, not a qa meeting. this one is about tooling. or I misunderstood what you were saying.
14:06:41 <tflink> linuxmodder: the qa meeting or #fedora-qa might be a better place for that
14:07:01 <linuxmodder> tflink,  noted
14:07:20 <tflink> alrighty, moving on
14:07:31 <tflink> #topic Rawhide Images
14:07:47 <tflink> I managed to miss this on the wiki a while back
14:08:00 <tflink> but the question of what to do when some base images can't be built has been raised
14:08:21 <tflink> jskladan: I assume this was something you added? is it still relevent enough to discuss?
14:08:42 <jskladan> the question is mostly applicable to "new" release that was never built before
14:09:05 <jskladan> since we are now in the "targeted run" mode, where we need to have the relevant base image ready, or we die
14:10:17 <jskladan> once we get the image built once, there is no problem, as there is "at least some" ready, and once the build succeeds, the new one will be used immediately
14:10:19 <tflink> can we fall back to the closest image if the desired one is not available?
14:10:38 <jskladan> well, we could, but it may not necessarily be the best idea
14:11:00 <jskladan> that's what we did for Rawhide (I manually copied one F24 image to have F25/rawhide name)
14:11:03 <tflink> what are our options, then?
14:11:05 <jskladan> but it has drawbacks
14:11:14 <kparal> if the task wants rawhide and there's no rawhide image available, I think we should just fail
14:11:29 <jskladan> like - when we install packages, it might or may not work
14:11:35 <jskladan> and then what to do with fails
14:11:49 <jskladan> etc
14:11:59 <jskladan> the sane option would be IMHO to just fail
14:12:17 <jskladan> but that would lead to tons of failed buildbot jobs, etc
14:12:47 <tflink> hrm
14:13:02 <kparal> can we detect what images we have even before we schedule it through buildbot?
14:13:03 <jskladan> we (kamil, martin and I) found no easy answer
14:13:11 <kparal> to avoid the failures
14:13:27 <tflink> yeah, I'm not coming up with anything brilliant, either
14:13:32 <kparal> could trigger just drop such tasks until the images are available?
14:13:37 <kparal> and log it, of course
14:13:52 <tflink> what kparal said makes the most sense to me - don't trigger for rawhide before we have an image
14:14:11 <tflink> if we have one image for that release, even if it's old, that should work, right?
14:14:19 <mkrizek> trigger is on different machines than images
14:14:27 <jskladan> tflink: yup, as soon as we have at least one, it's fine...
14:14:41 <jskladan> the other solution would be to just end the task gracefully
14:14:51 <jskladan> instead of putting it to trigger
14:14:59 <tflink> or both, I suppose
14:15:15 <tflink> I'm not really thinking of a way to make this automatic, though
14:15:16 <jskladan> because we allow for image specification in the formula
14:15:30 <tflink> not without quite a bit of effort
14:15:35 <jskladan> so the trigger might not necessarily know what image is really needed
14:15:44 <kparal> we will have a script that will distribute the images (via rsync or something), can the same script copy the list of those images to the trigger machine?
14:16:04 <kparal> hmm
14:16:12 <tflink> either way, the trigger may not know
14:16:12 <tflink> like jskladan pointed out
14:16:14 <jskladan> kparal: that IMHO just adds unnecessary complications + what I said earlier about formula&image seleciton
14:16:37 <jskladan> I'd be OK with just failing gracefully
14:16:45 <tflink> i can't think of a better idea
14:16:52 <kparal> I'm a bit worried it means silent failures
14:16:57 <tflink> but I would like to see alarm bells raised on the admin side
14:17:20 <jskladan> kparal: failing gracefully does not mean, that we can't log it
14:17:27 <jskladan> as we would from trigger
14:17:33 <kparal> yeah I know, but who reads them atm...
14:17:44 <mkrizek> until we have central logging, I'd just crash so we know
14:17:54 <jskladan> kparal: somebody would have to read those logs from trigger too, that's moot point
14:17:54 <mkrizek> even if that leads to flood in the mail
14:18:06 * jskladan needs to go AFK for a minute
14:18:45 <tflink> mkrizek +1
14:20:29 <kparal> mkrizek: yeah, I guess
14:20:42 * jskladan is back
14:20:57 <tflink> it sounds like there is some consensus that the "unavailable image" should crash, making sure that at least admins know
14:21:05 <jskladan> cool with me
14:22:26 <tflink> #agreed in the case where an image release is specified and no images from that release exist, the job should fail noisily enough so that admins find out about it
14:22:39 * tflink can redo if there are -1s or patches
14:23:37 <mkrizek> another reason to have central logging I guess
14:23:47 <tflink> yep
14:24:13 <tflink> if wishes were horses ...
14:24:35 <tflink> we'd all be eating steak :-D
14:25:16 <tflink> anyhow, moving on
14:25:36 <tflink> #topic ABI Checking
14:25:47 <tflink> as a quick update, this was pushed to dev last week, no?
14:25:55 <mkrizek> yes
14:26:07 <tflink> things running smoothly so far?
14:26:18 <mkrizek> no crashes afaik
14:26:49 <tflink> has someone been looking at the output to see if the check is working?
14:27:36 <mkrizek> I just checked the output of the first one that has run, looked good to me
14:27:53 <tflink> ok, anyone want to take an action item to make sure that either one of us or one of the libabigail folks is looking at some of the output?
14:28:13 <mkrizek> I can
14:28:46 <tflink> #action mkrizek to make sure that someone is looking at the abicheck task output to make sure it's running correctly, etc.
14:28:47 <tflink> thanks
14:28:58 <tflink> anything else on this ?
14:29:02 <coremodule> tflink, I'll check the ABI checker if you can provide a link...
14:29:12 <mkrizek> nothing here
14:29:43 <mkrizek> coremodule: http://taskotron-dev.fedoraproject.org/resultsdb/jobs?testcase=scratch.libabigail
14:29:43 <tflink> http://taskotron-dev.fedoraproject.org/resultsdb/results?testcase_name=scratch.libabigail
14:30:01 <tflink> once again :)
14:30:04 <coremodule> tflink, mkrizek, thanks.
14:30:06 <tflink> anyhow, moving on
14:30:24 <tflink> coremodule: thanks for looking at the results
14:31:03 <tflink> I don't have anything on the "potential other topics", skipping them but can come back at open floor
14:31:10 <tflink> #topic Tasking
14:31:16 <tflink> is anyone in need of stuff to do?
14:31:54 <tflink> as a side note, we need to figure out why the tmpwatch cronjobs on the taskotron masters aren't working
14:32:20 <tflink> taskotron01.qa has been sending out nagios warnings for a while now :(
14:32:52 <mkrizek> tflink: I sent an update note on that to the phab ticket earlier
14:33:31 <tflink> mkrizek: ah, I hadn't read that yet. thanks
14:33:57 <mkrizek> tflink: it was just a minute or so before the meeting :)
14:34:47 <tflink> if anyone finds themselves in a place where they need tasks, let me know or find something on the planning board
14:35:24 <tflink> #topic Open Floor
14:35:24 <tflink> Any other things to bring up?
14:35:34 * jskladan has nothing
14:35:58 <mkrizek> nothing here
14:36:54 * tflink sets the fuse
14:38:15 <tflink> thanks for coming, everyone
14:38:32 * tflink will send out minutes shortly
14:38:32 <tflink> #endmeeting