fedora-meeting-1
LOGS
20:01:12 <pwhalen> #startmeeting
20:01:12 <zodbot> Meeting started Wed Sep 19 20:01:12 2012 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:12 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore
20:01:12 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen
20:01:16 <pwhalen> .fas pwhalen
20:01:17 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:01:23 <bconoboy> .fas blc@
20:01:23 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:01:29 <dgilmore> hi
20:01:30 <masta> .fas parasense
20:01:30 <zodbot> masta: parasense 'Jon Disnard' <jdisnard@gmail.com>
20:02:01 <Frojoe> .fas Frojoe
20:02:01 <zodbot> Frojoe: jacwang 'Jordan Cwang' <jordan.cwang@gmail.com> - burningfool 'Jordan Cwang' <frojoe.21@gmail.com>
20:02:06 <dmarlin> .fas dmarlin
20:02:06 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:02:39 <pwhalen> so first item..
20:02:49 <pwhalen> #topic 1) F18 Build status - problem packages
20:03:13 <Southern_Gentlem> .fas jbwillia
20:03:13 <zodbot> Southern_Gentlem: jbwillia '' <vaioof@yahoo.com> - jbwilliams 'Jason Williams' <jb.williams@tiscali.co.uk>
20:03:19 <jcapik> .fas jcapik
20:03:20 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:03:32 <pwhalen> I think Peter said he would likely miss today. I have not had any real time to look at the ks logs.. does anyone have any updates on f18/19 problem packages?
20:04:14 <fossjon> I haven't been tracking it...
20:04:43 <Frojoe> Nor have I
20:05:17 <bconoboy> it looks like we've been hovering around 300 missing packages for weeks
20:05:24 <dgilmore> peter is on holidays
20:05:38 <dgilmore> bconoboy: well primary floodgates opened up
20:05:58 <dgilmore> we have had about 1k updated packages the last 2 days
20:06:04 <masta> are we talking about this: http://arm.koji.fedoraproject.org/status/
20:06:09 <bconoboy> dgilmore: okay, so builders will be busy, eh?
20:06:24 <dgilmore> bconoboy: well alot of it was built in updates-testing
20:06:31 <pwhalen> masta that page is very old and out of date
20:06:34 <dgilmore> bconoboy: but it might unstick some things
20:06:46 <dgilmore> Same |        Newer |        Older |        Local |       Remote |      Missing |
20:06:49 <dgilmore> ------------------------------------------------------------------------------------------
20:06:52 <dgilmore> 11820 |            8 |          155 |            1 |          311 |          329 |
20:07:06 <dgilmore> why we have 8 newer id like to know
20:07:15 <bconoboy> pwhalen: will you be managing koji-shadow while pbrobinson is away?
20:07:15 <dgilmore> they should get pushed to primary
20:07:21 <pwhalen> would be nice to bring it back, had shadow logs available for all to see
20:07:29 <dmarlin> I think pbrobinson mentioned python-greenlet needed some attention.   not sure if anyone has looked at it.
20:07:31 <pwhalen> bconoboy, I have been given access to the logs as is
20:07:42 <dgilmore> the 311 remote would be nice to work out if they are excluded or if there is some reason they are not built
20:07:58 <fossjon> dgilmore http://142.204.133.82/jon/koji/kc.f18.diff.html
20:08:25 <fossjon> gmt, fpdns, gdesklets, imagefactory, libservicelog, msp, olpc
20:08:40 <bconoboy> peter has mentioned somebody needing to look at python-greenlet
20:08:41 <fossjon> assuming its correct
20:09:20 <fossjon> i have inheritence turned on for f18 checks
20:09:42 <dgilmore> fossjon: thats wrong
20:09:51 <dsd> it looks like olpc-kbdshim was built manually, i guess the developer doesnt know that shadowing happens
20:09:56 <dgilmore> fossjon: the only place that should have inheritance turned on is rawhide
20:09:59 <bconoboy> #info same: 11820, newer: 8, older: 155, local: 1, remote: 311, missing: 329
20:10:00 <dsd> the equivalent build is also on primary - but it is in updates-testing
20:10:07 <dgilmore> dsd: ok'
20:10:17 <fossjon> bconoboy so your numbers match mine tho?
20:10:39 <bconoboy> fossjon: I'm just putting a meetingbot record from dgilmore's numbers
20:10:49 <fossjon> oh oh
20:11:45 <fossjon> well i can turn inherit off
20:11:47 <fossjon> :)
20:12:11 <fossjon> anyway, i havent really calculated if theres any major blockers for that
20:12:18 <fossjon> it'd be interesting to check
20:12:19 <dgilmore> bconoboy: my numbers were from fossjon's email today
20:12:33 <fossjon> so my numbers match my own then!
20:12:37 <pwhalen> #info python-greenlet still needs attention - http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1145082
20:13:01 <bconoboy> We also have a serious F19 blocker, but that's another topic
20:13:55 <pwhalen> do we have anyone here who would like to look at python-greenlet?
20:14:02 <dsd> we're using F18 for OLPC development, things seem as good as ever. updates-testing hasnt been pushed for a couple of weeks, so hasnt been tested, but dgilmore suggested today that there will be a push soon :)
20:14:57 <dgilmore> dsd: still waiting on packages to be signed
20:15:02 <dgilmore> but they are getting there
20:15:41 <fossjon> DEBUG util.py:257:             Requires: libxml2.so.2(LIBXML2_2.4.30)
20:16:12 <pwhalen> fossjon, was that the f17 build?
20:16:20 <fossjon> ya im checking python-greenlet now
20:16:58 <fossjon> which is weird because we have libxml2-2.7.8-8.fc17 built for f17
20:17:02 <fossjon> maybe its not tagged?
20:17:13 <fossjon> hmmm
20:17:29 <pwhalen> fossjon, ks issue, that may either fail as the f18 did
20:17:49 <pwhalen> or perhaps build..
20:18:12 <dsd> fossjon: got a link to that log? i think the lines above it might be interesting
20:18:29 <fossjon> http://arm.koji.fedoraproject.org/koji/getfile?taskID=1144414&name=root.log dsd
20:18:37 <fossjon> thats the failed v7hl log for python-greenlet
20:18:52 <dsd> ok, so the problem package is shared-mime-info
20:19:00 <dsd> built against an old libxml2
20:19:05 <fossjon> oh i thought it was the requires part :/
20:19:19 <dsd> 1 line above :)
20:20:24 <pwhalen> may be worth while to re-queue that build as it looks like an init buildroot issue with shadow
20:20:37 <pwhalen> move on thenn?
20:20:41 <dgilmore> yep
20:20:49 <pwhalen> #topic 2) What will we ship for F18? Format and platforms
20:21:00 <dgilmore> so my thoughts here
20:21:15 <dgilmore> we should make images for omap devices
20:21:28 <dgilmore> we should have the kickstart setup the image so it can be dd'd
20:21:37 <dgilmore> with no messing around after
20:21:50 <dgilmore> ideally we have a vexpress image also
20:22:16 <dgilmore> we would need images for kirkwood
20:22:28 <bconoboy> tegra?
20:22:36 <masta> highbank?
20:22:37 <dgilmore> tegra, highbank, imx, vexpress we should only need to have install images
20:22:52 <bconoboy> dgilmore: why?
20:23:21 <dgilmore> bconoboy: there is little point to images for them, if anaconda works
20:23:26 <dsd> fossjon: actually shared-mime-info is fine. i agree with just kicking off another build and hoping that the problem has gone
20:23:38 <dgilmore> bconoboy: hopefully we can get a working framebuffer on tegra rsn
20:23:45 <bconoboy> dgilmore: anaconda will only work on trimslices with new uboot versions which most trimslices do not have.
20:23:47 <dmarlin> has anyone tested anaconda on tegra?
20:24:00 <dgilmore> bconoboy: well it will be a requirement
20:24:05 <dgilmore> have to upgrade uboot
20:24:37 <dmarlin> I prefer to just create a flash image for trimslice... works on existing systems with no u-boot update
20:24:38 <bconoboy> dgilmore: I think that's a mistake.  we should make images for tegra this time around- use anaconda for f19.
20:24:44 <masta> dmarlin: with all the crazies with the new uboot, sry I tried and gave up
20:24:52 <dgilmore> bconoboy: why?
20:25:08 <dmarlin> dgilmore: because it works
20:25:14 <bconoboy> dgilmore: I'm not even *able* to boot with the new uboot on trimslice.  Telling everybody to upgrade will immediately break all F17 installs for one thing.
20:25:18 <dgilmore> dmarlin: but it wont
20:25:36 <bconoboy> GA doesn't work with the new uboot.
20:25:41 <dgilmore> so we have the case where in f18 we are going to have to be required to use dtb
20:26:01 <dmarlin> we can burn that bridge when we come to it.   :)
20:26:09 <bconoboy> +1
20:26:11 <dgilmore> bconoboy: did you file bugs with compulab?
20:26:16 <bconoboy> dgilmore: yes.
20:26:23 <dgilmore> dmarlin: it will be less than 1 month after GA
20:26:52 <dmarlin> that buys us a month then
20:27:01 <dgilmore> dmarlin: not at all
20:27:01 <bconoboy> dgilmore: I'm just saying, for F18, we shoudl support both.  No bootable images means we're raising the bar for using fedora on trimslice.  That's not desirable.
20:27:09 <dgilmore> because we need to be working on it now
20:27:29 <dgilmore> bconoboy: i disagree its raising the bar
20:27:51 <masta> can we have (shudder) two images for trimslice, one for the new uboot and another for the old? There are nasty complications with the new uboot
20:27:57 <masta> ?
20:28:13 <bconoboy> dgilmore: Forcing a firmware ugprade that breaks an existing installation so somebody can then run a PXE installer to try out F18 is raising the bar.  You must see that.
20:28:14 <dmarlin> masta: I'd prefer fewer images, not more
20:28:21 <masta> agreed
20:28:25 <dmarlin> masta: we already have more than we have time to test
20:28:37 <dgilmore> bconoboy: they wont be running a pxe installer
20:28:55 <dmarlin> with what we have, they won't be running at all
20:29:05 <dgilmore> bconoboy: we will have a boot.img like the boot.iso that can be dd'd onto a sdcard and will boot and run anaconda
20:29:28 <dmarlin> dgilmore: and you have tested this?
20:29:40 <masta> I believe wcohen has his TS working on the new uboot, but so far been unable to reproduce his results
20:29:50 <dgilmore> dmarlin: not yet. no one has tested any f18 thing right now
20:30:01 <dmarlin> exactly
20:30:12 <dgilmore> dmarlin: your missing my points
20:30:41 <bconoboy> Maybe we should take a step back- are we talking about F18 final or f18 alpha?  Because right now we're pre-alpha.
20:30:43 <dgilmore> we do need to have a clear list of what we will deliver
20:30:55 <bconoboy> And in our pre-alpha state we're way far behind where we were with F17.
20:31:16 <dgilmore> bconoboy: ideally we ship the same things for alpha beta and ga
20:31:16 <bconoboy> So I'm all for adding cool stuff to F18.  But let's get alpha criteria down.
20:31:29 <bconoboy> dgilmore: Ideally we ship in 2012.
20:31:36 <dgilmore> bconoboy: if we ship images for tegra for alpha and installer images for beta and ga so be it
20:31:37 <bconoboy> anaconda is not ready.
20:31:59 <bconoboy> so if anaconda becomes ready for beta, let's use it for beta
20:32:01 <dgilmore> bconoboy: thats BS
20:32:16 <fossjon> i heard anaconda was broken with f18 for primary?
20:32:19 <dgilmore> anaconda is buggy
20:32:19 <fossjon> someone told me
20:32:32 <fossjon> is that still true?
20:32:33 <dgilmore> fossjon: if it was broken we wouldnt have shipped alpha
20:32:41 <dgilmore> its got bugs
20:32:45 <dgilmore> its not perfect
20:32:49 <dgilmore> but its not broken
20:32:54 <masta> once we get a working f18 kernel/userland on the latesr TS uboot, I'll test anaconda over pxe.
20:32:55 <bconoboy> it doesn't support text mode yet, right?
20:33:05 <dgilmore> bconoboy: it does
20:33:18 <dgilmore> bconoboy: its just not in the way livemedia-creator wants
20:33:19 <bconoboy> the rewrite is done?
20:33:25 <dgilmore> bconoboy: its not complete
20:33:29 <dgilmore> but it does work
20:33:48 <dgilmore> bconoboy: we need to rely on people doing there work and do ours
20:34:00 <dgilmore> not sit around and go oh thats broken so ill do something else
20:34:33 * dgilmore is frustrated right now that we are getting hung up on things and not moving forward generally
20:34:34 <fossjon> right but if something is buggy on there end it makes no sense to work with it on our end until they fix it right?
20:34:42 <fossjon> their*
20:35:01 <dgilmore> fossjon: no, the idea of alpha is to make beta better
20:35:06 <dgilmore> and GA better still
20:35:16 <bconoboy> dgilmore: I'm not exactly sure what you're proposing.  If livemedia-creator support isn't finished and we can't use it, what are you suggesting?
20:35:22 <masta> ok so we try to move forward with omap and vexpress... we are hung up on tegra
20:35:49 <dgilmore> bconoboy: im trying to get us to have a list of what the fuck we are going to ship. in an ideal world
20:36:07 <masta> assuming the next kernel is working on omap, can we then move to make an image using the tool?
20:36:16 <dgilmore> if we end up needing to go down different routes so be it
20:36:34 <dmarlin> the world is not ideal, so we should also have a fall-back plan
20:36:48 <dmarlin> minimal set of things to release
20:37:36 <bconoboy> dgilmore: Okay, ideal world, but not necessarily The Plan of Action?  I'm cool with that.
20:37:46 <dmarlin> this is just my personal preference, but I'd like to just make images for things that 'can' boot from flash (trimslice, panda)
20:38:21 <dmarlin> easy to make, easy to install, easy to test
20:38:26 * masta +1
20:38:48 <bconoboy> I think, ideally, we could include directly writeable images as we did in F17 for the same platforms as F17.  On top of that we would add installer support for platforms where it makes sense.  Not sure if that's anything other than highbank.  Perhaps armada-xp if upstream support lands in time.
20:39:23 <bconoboy> Ideally, we'll consolidate on a unified kernel for the targets that support it.
20:39:26 <dmarlin> unlikely armada-xp will be upstream for f18
20:39:36 <bconoboy> I think its support is in 3.7
20:39:54 <dgilmore> bconoboy: i suspect that we will ship with 3.6
20:40:00 <dgilmore> but 3.7 will require dtb
20:40:18 <dgilmore> and we will get 3.7 when 3.7.1 is released
20:40:41 <bconoboy> Is there anything we can do now to handle dtb in a 3.7 update?
20:41:17 <dgilmore> the dtb format is supposed to be stable
20:41:23 <dgilmore> so we should be using dtb in 3.6
20:41:36 <bconoboy> how?
20:41:39 <dgilmore> we should ship f18 using dtb everywhere
20:41:45 <dgilmore> we have to work that out
20:41:52 <dgilmore> ideally vendors ship the dtb
20:41:53 <bconoboy> okay, probably beyond scope for this meeting
20:42:02 <dgilmore> yes
20:42:20 <bconoboy> If we can use dtb everywhere with f17 3.6 I'm for it.  It sounds aspirational though.
20:43:17 <dgilmore> we really dont have much choice
20:43:40 <bconoboy> imx?
20:43:41 <dmarlin> has anyone managed to boot using dtb on any of our device (except highbank)?
20:43:57 <dgilmore> dmarlin: ive booted panda with an appended dtb
20:44:05 <bconoboy> I think we're supporting vexpress, omap, tegra, highbank, kirkwood.  Anything else? Is imx staying?
20:44:10 <dgilmore> which is not the ideal way to do it
20:44:20 <dgilmore> bconoboy: id be ok dropping it
20:44:44 <dgilmore> not sure thatthe framebuffer will ever get upstream
20:45:02 <dgilmore> i think the efika smarttop is sold out
20:45:09 <dgilmore> you can only get the smartbook
20:45:15 <dgilmore> and it only works with f13
20:45:27 <dmarlin> bconoboy: for f17 'blockers' was a smaller list... same for f18?
20:45:29 <bconoboy> #info We may drop IMX support
20:45:39 <pwhalen> +1 to dropping imx
20:45:45 <dmarlin> +1
20:45:57 <bconoboy> #info Plan is to support vexpress, omap, tegra, highbank, kirkwood in F18
20:46:48 <bconoboy> #info Reach-goal is to support DTB on all possible platforms with 3.6 kernel in preparation for unified 3.7 kernel
20:46:48 <dmarlin> bconoboy: for f17, we only blocked on vexpress, panda, and highbank, correct?
20:46:57 <bconoboy> dmarlin: think so
20:47:03 <bconoboy> anybody want to change that?
20:47:04 <dmarlin> bconoboy: same for f18?
20:47:23 * dmarlin is for keeping it the same
20:47:24 <bconoboy> #info Blocker platforms: vexpress, omap, highbank
20:47:26 <pwhalen> those seem reasonable to me
20:47:32 <dmarlin> +1
20:47:41 <pwhalen> bconoboy, no panda?
20:47:46 <pwhalen> sorry
20:47:48 <pwhalen> nm
20:47:49 <bconoboy> :-)
20:47:57 <dgilmore> id like tegra to be a blocker if we get the tergadrm module in
20:48:01 <bconoboy> That's a good question though- we going to support beagle and panda?
20:48:03 <dmarlin> change omap -> panda
20:48:04 <dgilmore> it then becomes a viable desktop
20:48:10 <pwhalen> dgilmore, agreed
20:48:20 <masta> +1 the blocker platforms
20:48:24 <bconoboy> #info Tegra becomes a blocker iff tegradrm support lands
20:48:24 <dmarlin> dgilmore: _1
20:48:30 <dmarlin> dgilmore: +1
20:49:04 <pwhalen> did we reach a consensus on what we ship, or revisit?
20:49:18 <dgilmore> pwhalen: we did not
20:49:28 <bconoboy> There's requirements and goals, right?
20:49:36 <pwhalen> shall we come back to this next week, or continue? we are closing in on the hour
20:49:44 <dgilmore> lets take it to the list
20:49:45 <bconoboy> I'd say requirements are: Directly installable images for any target we can't use anaconda on
20:49:50 <dgilmore> ill kick off a thread
20:49:54 <bconoboy> sounds good
20:49:57 <pwhalen> ok
20:50:06 <dgilmore> we need to have all platforms supported be installable
20:50:12 <dgilmore> how that works is up to debate
20:50:24 <bconoboy> #info Installer vs Writable image debate to follow on Fedora's arm mailing list
20:50:50 <pwhalen> #topic 3) Fedora 18 kernel status a)mmc driver issues b)Kernel testers (including those willing to look at FTBFS)
20:51:02 * dgilmore is about to test a omap kernel
20:51:13 <dgilmore> rebooting into it now
20:51:14 <pwhalen> dgilmore, we eagerly await
20:51:17 <bconoboy> dgilmore: Are you testing kernel changes or anaconda changes?
20:51:22 <bconoboy> er, dracut rather
20:51:26 <bconoboy> s/anaconda/dracut/
20:51:28 <dgilmore> bconoboy: its actually both
20:51:36 <dmarlin> pwhalen has tested 3.6 on f18 fof vexpress
20:51:44 <dgilmore> bconoboy: enabled OMAP_DRM as a module in the kernel
20:51:53 <dgilmore> and a dracut change to pull the module in
20:51:53 <bconoboy> dmarlin: that test failed because of mmc issue, y?
20:52:02 <dmarlin> bconoboy: nope, it works
20:52:14 <bconoboy> really?
20:52:16 <dmarlin> bconoboy: unfortunately, rc5 breaks again
20:52:23 <dmarlin> but due to memory overlap
20:52:39 <bconoboy> ah
20:52:42 <pwhalen> https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing#kernel-3.6.0-0.rc5.git2.1.fc18
20:52:55 <pwhalen> #link https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing#kernel-3.6.0-0.rc5.git2.1.fc18
20:53:02 <bconoboy> dgilmore: Are you making changes to dracut so we get the modules on each supported platform, or is it just a change to support omap right now?
20:53:03 <dgilmore> ok thats special
20:53:04 <dgilmore> http://www.fpaste.org/5YAw/
20:53:07 <pwhalen> those were my latest
20:53:21 <dgilmore> bconoboy: right now omap but we will need to do all platforms
20:53:37 <dgilmore> the dma engine gets loaded but still not used
20:53:59 <bconoboy> Just to repeat what I said yesterday: I think we should build the mmc drivers into the kernel, at least for alpha, so we can test the total platform right away.
20:54:42 <dmarlin> bconoboy: we are working on that
20:54:56 <bconoboy> dmarlin: I mean =y rather than =m
20:55:04 <dmarlin> bconoboy: interim solution until dgilmore gets dracut fixed
20:55:33 <bconoboy> dmarlin: these are just scratch kernels though, no?
20:55:41 <dmarlin> bconoboy: yes, at this time
20:55:42 <masta> maybe we need to make the dma engine =y and then =m the other stuff ?
20:56:03 <masta> of course =y all the mmc code path would be handy
20:56:12 <bconoboy> Okay, if this is still an issue next wednesday can we move to =y in non-scratch kernels?
20:56:51 <masta> +1
20:57:01 <masta> we cannto wait forever
20:57:12 <bconoboy> dgilmore?
20:57:20 <dmarlin> +1, we can always revert to =m later, when working
20:57:55 <dgilmore> bconoboy: i dont think it will matter
20:58:05 <dgilmore> because i think we will ahve it fixed by then
20:58:06 <bconoboy> why?
20:58:11 <dmarlin> cool
20:58:17 <pwhalen> if not...?
20:58:18 <bconoboy> dgilmore: in that case can we have your tentative support if it isn't fixed?
20:58:29 <dgilmore> bconoboy: im staying out
20:58:34 <dgilmore> ill make up my mind later
20:58:35 <dmarlin> bconoboy: think positive.  :)
20:58:47 <bconoboy> :-)
20:58:48 <bconoboy> okay
20:59:10 <bconoboy> #action dgilmore is fixing the kernel and dracut to support initramfs inclusion of mmc drivers for all supported platforms
20:59:18 <pwhalen> alright, positive thoughts on 'speak like a pirate day'. This will be fixed by next week. no ifs
20:59:33 <masta> yar!
20:59:36 <bconoboy> #info Tentative agreement to build modules in if it's not fixed in 1 week
20:59:47 <bconoboy> #undo
20:59:48 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x3ac16fd0>
21:00:00 <bconoboy> #info Tentative agreement to build mmc drivers into vmlinux if it's not fixed in 1 week
21:00:23 <pwhalen> and the last 30 seconds...
21:00:26 <pwhalen> #topic 4) Your topic here
21:00:41 <bconoboy> F19 needs glibc love
21:00:53 <bconoboy> anybody available to dig in?
21:01:02 <kwizart> !
21:01:16 <kwizart> is there support for out-of-tree kernel module ?
21:01:35 <kwizart> on f17 kernel-devel it's failing with:
21:01:41 <bconoboy> I've narrowed it down to a change between glibc-2.16.90-5 and glibc-2.16.90-6
21:01:46 <kwizart> /usr/src/kernels/3.4.2-3.fc17.armv5tel/arch/arm/include/asm/timex.h:15:24: fatal error: mach/timex.h: No such file or directory
21:01:59 <dgilmore> kwizart: this is not the right forum for that question
21:02:05 <masta> bconoboy: is that the significant f19 problem?
21:02:33 <bconoboy> the reason f19 has 1500 unbuilt packages is this glibc problem.
21:03:10 <masta> bconoboy: tell me like I'm five, what is the problem? FTBFS all over? only in arm?
21:03:24 <bconoboy> ftbfs for armv5tel
21:03:38 <bconoboy> hang on, I'll pull up a build log..
21:03:53 <bconoboy> (on an unrelated topic, why is arm.koji so slow?)
21:03:53 <pwhalen> last one was v7
21:03:57 <pwhalen> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1140903
21:04:31 <bconoboy> masta: see https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1135741
21:05:00 <bconoboy> The failure in -2 has been fixed.  The problem in -10 and -11 is current.
21:05:16 <bconoboy> pwhalen: What you posted is for -2- I Fixed that :-)
21:05:21 <pwhalen> bconoboy, ctyler was looking at that yesterday, it seemed to get a little quicker. he mentioend a bottleneck on the db server but yes, horribly slow.
21:05:31 <pwhalen> awesome
21:05:39 <bconoboy> masta: Are you volunteering on glibc? :-)
21:05:48 <pwhalen> hosts page, forget about it
21:06:03 <fossjon> our hosts page is horrible because of this sessions/states table in postgresql which has grown to be huge i believe
21:06:13 <bconoboy> #info F19 glibc build failure is blocking 1500+ builds
21:06:39 <bconoboy> #info glibc failure was introduced between glibc-2.16.90-5 and glibc-2.16.90-6
21:07:50 <masta> bconoboy: I will see what I can do, but I'm cautious about owning it.... lack of self confidence
21:08:03 <fossjon> nothings permanent :)
21:08:16 <bconoboy> masta: I have a diff if you want to run through it :-)
21:08:25 <bconoboy> pwhalen: I think we're petering out
21:08:43 <pwhalen> sorry, was looking at glibc..
21:08:46 <pwhalen> anything else?!
21:09:00 <pwhalen> last call....
21:09:07 <pwhalen> #endmeeting