15:00:13 <pwhalen> #startmeeting Fedora ARM & AArch64 Status Meeting
15:00:13 <zodbot> Meeting started Tue Mar 17 15:00:13 2015 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:13 <pwhalen> #chair pwhalen bconoboy pbrobinson dgilmore hrw jsmith kylem awafaa ddutile dmarlin
15:00:13 <zodbot> Current chairs: awafaa bconoboy ddutile dgilmore dmarlin hrw jsmith kylem pbrobinson pwhalen
15:00:26 <pwhalen> good morning folks
15:00:29 <hrw> hi
15:00:31 <jsmith> Good morning!
15:00:41 <pbrobinson> morning
15:00:57 <mlangsdorf> hello
15:01:13 <bconoboy> howdy
15:01:42 <pwhalen> thanks for coming everyone, lets give it another minute for others to join
15:02:09 <jwb> hi, i am here
15:02:47 <pbrobinson> pwhalen: lets do this
15:02:48 <pwhalen> many of you came to talk about the kernel, lets begin there
15:02:54 <ddutile> hi!
15:02:58 <pwhalen> #topic 1) ==== Fedora AArch64 Kernel Maintenance ====
15:03:19 <bconoboy> Who's leading this discussion?
15:03:31 <pwhalen> bconoboy, feel free
15:03:34 <bconoboy> Okay...
15:03:39 <pbrobinson> 4.0rc4 is in mainline now, it's not even building for aarch64
15:03:50 <bconoboy> So, we have this thing called kernel-arm64 in fedorahosted
15:04:07 <bconoboy> Historically we've been using it as a feeder for both arm64 patches into fedora as well as red hat's PEAP OS
15:04:40 <bconoboy> But we're reaching a point where upstream-first is more viable for fedora
15:04:45 <pbrobinson> which is basically a random dump of patches from the other OS which randomly gets updated and pulled into Fedora as a lump for extended aarch64 support
15:05:09 <pbrobinson> as far as I'm aware is the last big hold out the ACPI patch set?
15:05:13 <bconoboy> It's not random, but it's not good for maintenance.
15:05:38 <bconoboy> So I'd like to put out there for discussion what we might do instead
15:05:40 <pbrobinson> bconoboy: it is random for anyone looking from the outside ;-)
15:05:59 <bconoboy> I think it would be really nice if we dropped the megapatch
15:06:05 <hrw> it is 'magic patch with lot of stuff'
15:06:19 <bconoboy> And pulled in only enough individual patches as necessary to be feature equivalent to f21, plus any backported bugfixes.
15:06:24 <pbrobinson> so has anyone documented or know what's in the mega patch vs pure upstream
15:06:39 <kylem> it's a git tree, of course we know what's in it
15:06:47 <bconoboy> There's individual commits on kernel-arm64 so it's very well documented.
15:06:53 <msalter> mostly acpi related
15:06:55 <kylem> the point is, it was originally a way for vendors to contribute to getting their stuff tested
15:07:00 <kylem> but none of the vendors bothered.
15:07:17 <kylem> and since acpi isn't enabled by default, the question is, why are we wasting time?
15:07:20 <pbrobinson> and for us to actually have working hardware in Fedora
15:07:45 <jwb> bconoboy, fwiw, the git tree kylem mentioned is clearer than kernel-arm64.patch
15:07:55 <kylem> the only thing in there that's required for that, is the seattle xgbe a0 driver.
15:08:00 <pbrobinson> kylem: beats me, it was my understanding that the ACPI patch set was needed for things to actually work
15:08:03 <bconoboy> Right, so basically the end result we're looking for is to converge on a 100% upstream kernel and stability on supported platforms
15:08:07 <kylem> pbrobinson, well, no.
15:08:31 <kylem> but frankly, i'm sick of people coming and whining to me every week saying the tree is broken for some reason or another.
15:08:38 <bconoboy> pbrobinson: we don't need the acpi patch set
15:08:38 <dmarlin> bconoboy: what will we lose by doing that?
15:08:48 <jwb> pbrobinson, aside: it not building -rc4 is likely my fault when i rebased kernel-arm64.patch yesterday.  i'll take a look at what i did wrong later
15:08:54 <bconoboy> dmarlin: it's nice to have, but not essential
15:09:00 <dmarlin> bconoboy: what is?
15:09:08 <bconoboy> acpi patch set is nice to have but not essential.
15:09:16 <msalter> jwb: I pushed out rebase to fedorahosted yesterday
15:09:22 <dmarlin> bconoboy: is ACPI *all* that is in that patch?
15:09:23 <kylem> msalter, has anyone tested whether acpi-by-default actually works when we don't pass dtb from uefi?
15:09:25 <pbrobinson> jwb: I'm not trying to blame, I just don't have time to look at it so I asked if kylem could
15:09:38 <bconoboy> dmarlin: No, there are other patches
15:09:43 <jwb> pbrobinson, didn't think you were.  i looked at it.  it's my fault.
15:10:01 <dmarlin> bconoboy: ok, that's what I was asking about... what will we lose... we don't really want to lose any functionality
15:10:05 <hrw> dmarlin: acpi, seattle ethernet, sbsa uart are added stuff in patch
15:10:27 <dmarlin> hrw: thanks.  we really don't want to lose seattle ethernet, sbsa uart, etc.
15:10:36 <kylem> sbsa uart is pointless if we drop acpi.
15:10:46 <bconoboy> So, if we dropped the patch series we'd lose acpi, seattle a0 network support, and a few other odds&ends (msalter knows best here)
15:10:47 <msalter> kylem: I don't think so. grub always passes a DTB
15:11:15 <kylem> msalter, hmm, probably worth checking.
15:11:16 <kylem> ok.
15:11:29 <bconoboy> The patch set is somewhat at odds with our upstream-first ideals
15:11:33 <kylem> bconoboy, a0 is easy to keep, since it's alongside the b0 stuff.
15:11:34 <pbrobinson> so it sounds like a good start would be to drop the patch, add seattle ethernet as a standalone patch and see where we stand
15:11:50 <hrw> looks like psci support is in patch too
15:11:57 <msalter> no
15:12:07 <bconoboy> We also have some stability fixes that might not be in 4.0rcX and certainly aren't in earlier kernels
15:12:20 <hrw> smbios3 support
15:12:28 <bconoboy> So the question is 2-fold: How do we handle earlier kernels, how do we handle devel kernels?
15:12:59 <pbrobinson> I think we leave <=3.19 with the patchset, it's done and then move forward from here for 4.0
15:13:16 <bconoboy> Because there's at least one mustang ethernet driver bug that is causing delays to the f22 alpha compose that is the result of lack of maintenance
15:13:42 <bconoboy> Okay, so f21 gets the patchset, f22 does not?
15:13:55 <hrw> console= hacks are there as well
15:13:56 <bconoboy> (or f22 gets the "something else" that is tbd)
15:14:01 <pbrobinson> if we then need specific patches we can pull them in as necessary like we do for the other arches, it then makes it easier for jwb/me to drop them when they do land upstream or are no longer needed
15:14:11 <kylem> what peter said.
15:14:25 <kylem> bconoboy, that's f21, not f22.
15:14:26 <msalter> the fix for that ethernet bug is upstream
15:14:51 <kylem> the xgene crap is because they didn't submit to stable when it got merged upstream because f&*@*ing davem.
15:15:08 <pbrobinson> msalter: not in the current stable F-21 kernel
15:15:38 <pbrobinson> although I did notice 3.19 should be on it's way to F-21 soon
15:15:38 <msalter> it should have been pulled into upstream stable tree
15:15:52 <msalter> but apparently not
15:15:53 <hrw> 64bit dma mask for xhci-plat (iirc needed to get usb at all) is also still in patch
15:16:03 <pbrobinson> msalter: it's not in 3.18, I've built a custom kernel to try and move forward
15:16:36 <bconoboy> Since it isn't in the fedora stable tree, perhaps we leave the megapatch as is for <=3.19 as pbrobinson suggests, but also backport the ethernet fix to <=3.19 as a separate patch. yes?
15:16:37 <pbrobinson> hrw: separate patches can be reviewed on an as needed basis
15:16:43 <hrw> pbrobinson: yep
15:17:05 <pbrobinson> bconoboy: I already have that local for my test kernel so that bit is easy
15:17:35 <bconoboy> Okay, so I think we have a plan....
15:17:37 <hrw> do we have TLB fix as separate one already or need to add?
15:17:48 <pbrobinson> hrw: it's in rc4
15:18:02 <hrw> pbrobinson: and needs backports for <3.19?
15:18:05 <bconoboy> <=3.19 kernels get fedorahostd kernel-arm64 megapatch, plus *separate* backports of bugfixes
15:18:25 <bconoboy> >=4.0 kernels get individual patches (no megapatch)
15:18:34 <pbrobinson> hrw: don't worry, I can deal with it, presumably upstream will be pulling it back anyway to stable releases
15:18:37 <bconoboy> Is everybody happy with that?
15:18:44 <hrw> +1
15:18:44 <pwhalen> +1
15:18:46 * pbrobinson is very happy!
15:19:01 <bconoboy> kylem?
15:19:04 <bconoboy> jwb?
15:19:18 * hrw waits for 4.0-rc4-megapatchedited to finish building
15:19:27 <jwb> i'm happy with whatever makes kylem happy
15:19:40 <kylem> i am never happy, so good luck with that
15:19:41 <jwb> but split out patches sounds good to me
15:19:52 <bconoboy> kylem: For you, does it make you less unhappy? ;-)
15:20:02 <ctyler> I'm unclear on the acpi situation. I don't want to regress to non-acpi...
15:20:13 <kylem> anything that's less of a nuisance to me is a +1.
15:20:26 <bconoboy> ctyler: individual patch if we decided to pull it in.
15:20:33 <bconoboy> #agreed <=3.19 kernels get fedorahostd kernel-arm64 megapatch, plus *separate* backports of bugfixes
15:20:35 * dmarlin just wants a fedora kernel that works (no loss of features)
15:20:42 <bconoboy> #agreed >=4.0 kernels get individual patches (no megapatch)
15:21:01 <bconoboy> Okay, so what individual patches get pulled in is something we can discuss now or later
15:21:08 <pbrobinson> later on
15:21:17 <pbrobinson> it's not a discussion point for this meeting
15:21:18 <ctyler> +1
15:21:25 <bconoboy> Works for me.  We done with this topic then?
15:21:26 <pbrobinson> if we want the meeting to end today
15:21:27 <pwhalen> ok , awesome.
15:21:37 <pwhalen> #topic 2) ==== Package Status & Issues  ====
15:21:44 <pbrobinson> ghc is the major one
15:21:57 <kylem> seems like it has been for several weeks running.
15:22:08 <pbrobinson> there is no visible movement on that one
15:22:32 <pbrobinson> kylem: it has been since late Jan
15:22:38 <bconoboy> bz#?
15:22:41 <pbrobinson> there's a few others that have come up
15:23:03 <pbrobinson> ghc rhbz 1195231
15:23:27 <pbrobinson> then there's strace rhbz # 1201777
15:23:31 <kylem> we really need a better way to track these things... bugzilla is so damned slow to reply to queries.
15:23:39 <hrw> strace upstream is now good state
15:23:52 <pbrobinson> hrw: now or not?
15:23:52 <hrw> strace upstream is same as fedora maintainer
15:23:54 <hrw> now
15:24:03 <hrw> pbrobinson: yesterday last fixes went
15:24:07 <bconoboy> My only update on 1195231 is that jens has asked how upstream developers can get access to fedora aarch64 hosts, we're working out the method to use linaro's lab right now
15:24:07 <pwhalen> #info GHC BZ#1195231
15:24:17 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1195231
15:24:28 <bconoboy> Basically they have a lab that the public can use, you fill out a form, get access
15:24:40 <hrw> pbrobinson: strace needs several backports to be working.
15:24:41 <awafaa> bconoboy: surely it's just a matter of filing in the webform?
15:24:50 <bconoboy> We're doing a test run of the form right now- assuming that works we'll hand the URL over to the ghc upstreams to try it out
15:25:00 <pwhalen> www.linaro.org/leg/servercluster/
15:25:01 <bconoboy> awafaa: that's the idea
15:25:09 <pbrobinson> then we have what looks to be a binutils problem (rhbz # 1201778 ) which has shown itself via a elfutils FTBFS
15:25:26 <bconoboy> our own pwhalen is hooked in on the maintenance of the cluster btw ;-)
15:25:46 <awafaa> bconoboy: well it works, the io.js guys went to http://www.linaro.org/leg/servercluster/ and got access pretty quickly
15:25:46 <pbrobinson> poor pwhalen
15:25:49 <pwhalen> :)
15:26:01 <bconoboy> awafaa: form was filled in just a few hours ago, I don't know what's followed yet
15:26:16 <awafaa> ah ok, /me STFU :)
15:26:30 <bconoboy> awafaa; hot of the press, as it were ;-)
15:26:38 <pbrobinson> bconoboy: why is it called a cluster? It's just a group of devices.... it's not a cluster
15:27:00 <awafaa> pbrobinson: because!
15:27:02 <bconoboy> pbrobinson: Perhaps they don't mean it in a technical sense
15:27:46 <bconoboy> There are many sayings that begin with "cluster $verb"
15:27:52 <bconoboy> and cluster $noun
15:27:53 <pbrobinson> awafaa: you have _SO_ transitioned to marketing...
15:28:08 <pbrobinson> anyway moving on....
15:28:28 <pwhalen> no other problem packages?
15:28:29 <pbrobinson> the last one is xorg-x11-drv-qxl
15:28:34 <pwhalen> ah, yes
15:28:40 <hrw> pbrobinson: I prefer awafaa in marketing than in fashion ;D
15:28:41 <pbrobinson> I was hoping to get hrw to have a look at that
15:28:51 <pbrobinson> hrw: TRUE!
15:29:35 <pwhalen> #info xorg-x11-drv-qxl fails to build
15:29:39 <bconoboy> hrw: will you look at xorg-x11-drv-qxl?
15:29:40 <pwhalen> #link https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2923805
15:29:43 <bconoboy> (and is there a bz?)
15:29:44 <hrw> I will check
15:29:46 <pbrobinson> the xorg-x11-drv-qxl is rhbz 1201877
15:30:05 <bconoboy> #info  xorg-x11-drv-qxl is rhbz 1201877, hrw to investigate
15:30:15 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1201877
15:30:38 <pbrobinson> and that's it from my current list
15:30:42 <pwhalen> thanks pbrobinson
15:30:51 <bconoboy> #info binutils ftbfs due to elfutils bug, rhbz # 1201778
15:31:04 <bconoboy> hrw: what was that about strace?
15:31:36 <hrw> bconoboy: fedora maintainer is also upstream maintainer. current git HEAD has all required fixes
15:31:37 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1201778
15:31:41 <pbrobinson> bconoboy: there is movement in the BZ so I think that should be done RSN
15:31:52 <bconoboy> okay, cool
15:31:53 <yselkowitz> bconoboy, I think you mean elfutils ftbfs due to binutils bug?
15:32:03 <hrw> bconoboy: there were discussions on strace-devel ML about fixing 'this and that' and work got done
15:32:12 <bconoboy> yselkowitz: could be
15:32:17 <pbrobinson> yselkowitz: he does
15:32:46 <bconoboy> #undo
15:32:46 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0xd656650>
15:32:46 <bconoboy> #undo
15:32:46 <zodbot> Removing item from minutes: INFO by bconoboy at 15:30:51 : binutils ftbfs due to elfutils bug, rhbz # 1201778
15:32:59 <pbrobinson> the binutils/elfutils is the current F-23 big blocker of builds
15:32:59 <bconoboy> #info elfutils ftbfs due to binutils bug, rhbz # 1201778
15:33:05 <bconoboy> #link  https://bugzilla.redhat.com/show_bug.cgi?id=1201778
15:33:39 <pwhalen> any others?
15:33:44 <pbrobinson> not from me
15:34:14 <pwhalen> #topic 3) ==== F22 - Beta Testing (armhfp) ====
15:34:26 <pwhalen> #link https://fedoraproject.org/wiki/Test_Results:Current_Summary
15:34:57 * pbrobinson hasn't had time to do much testing this week
15:35:07 <pwhalen> F22 Beta TC2 is the current
15:35:26 * yselkowitz tested beta tc1 on qemu the other day
15:35:47 <yselkowitz> has pandaboard been fixed yet?
15:36:00 <pbrobinson> yselkowitz: yes, as of rc3
15:36:02 <pwhalen> nothing new that is arm specific.
15:36:02 <dgilmore> yselkowitz: I believe so
15:36:15 <pwhalen> #info Blivet depends on library that can't handle sizes >= 16 EiB
15:36:23 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1200812
15:36:33 <pwhalen> hit that for installations, but all arches are affected
15:36:39 <hrw> pwhalen: ;( my new pendrive will not work
15:36:54 <pbrobinson> not really an issue on my network
15:37:40 <pwhalen> hrw, er, talk to pbrobinson :)
15:38:02 <pwhalen> thank yselkowitz i noticed your results
15:38:03 <pwhalen> thnaks
15:38:29 <yselkowitz> if pandaboard is fixed then the wiki should be updated
15:38:54 <pwhalen> yselkowitz, once someone confirms. by all means, feel free to update if you test it
15:39:08 <pbrobinson> it is a wiki afterall
15:39:29 <pwhalen> #topic 4) ==== F22 - Alpha Update (aarch64) ====
15:39:31 <yselkowitz> if it's worth testing I will then
15:39:43 <hrw> how big SD card is needed for f22 install tests? 4GB is enough?
15:39:50 <jwb> i have a question whenever there is open floor
15:39:56 <hrw> jwb: at the end
15:40:03 <yselkowitz> hrw, only for minimal
15:40:03 <dgilmore> hrw: depends what image you test
15:40:16 <dgilmore> hrw: some images need 8gb
15:40:21 <hrw> dgilmore: minimal. I have EA1 panda which is insanely slow
15:40:34 <dgilmore> hrw: minimal fits in 2GiB
15:40:36 <pwhalen> hrw, 4GB is enough for minimal
15:40:38 <yselkowitz> hrw, 4gb is plenty for minimal
15:40:40 <hrw> cool
15:41:21 <pbrobinson> so we're moving towards an alpha, there's a few issues, I hope to have it bashed into shape by EOW
15:41:50 <bconoboy> anything you need help with?
15:42:33 <pbrobinson> the fix for xorg-x11-drv-qxl would be useful as it's pulled in via some things
15:43:39 <pbrobinson> that's all on my list atm that is possibly blocking alpha
15:44:38 <pwhalen> anything else for the aarch64 alpha?
15:45:09 <pbrobinson> not from me
15:45:37 <pwhalen> #topic 5) == Open Floor ==
15:45:57 <jwb> o/
15:46:41 <jsmith> FWIW, USB is not working on F22 Alpha on BeagleBone Black...
15:46:46 <bconoboy> anybody get their 96 board booting fedora?
15:46:49 <jwb> pbrobinson, we're still carrying a handful of arm-dts-am335x patches.  what is going on with those?
15:47:34 <pbrobinson> jwb: I've got them on my list to review before beta, I've just not had time in the last couple of weeks
15:48:45 <pwhalen> bconoboy, not *yet*
15:49:03 <pbrobinson> jwb: generally they have been terrible pushing them upstream, I'm hoping some recent changes might help that
15:49:31 <pbrobinson> bconoboy: not had time to look at it, I'm hoping soon
15:50:23 <pwhalen> anything else for open floor?
15:51:16 <pwhalen> #endmeeting