21:01:22 <pwhalen> #startmeeting Fedora ARM status meeting
21:01:22 <zodbot> Meeting started Wed Jan  8 21:01:22 2014 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:01:22 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore dmarlin jdisnard handsome_pirate msalter ahs3 agreene jcapik ddd
21:01:23 <zodbot> Current chairs: agreene ahs3 bconoboy ctyler ddd dgilmore dmarlin handsome_pirate jcapik jdisnard jonmasters msalter pbrobinson pwhalen
21:01:32 <pwhalen> Happy New Year!
21:01:36 <pwhalen> .fas pwhalen
21:01:36 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
21:01:37 <dmarlin> .fas dmarlin
21:01:42 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
21:01:42 <bconoboy> .fas blc@
21:01:45 <zodbot> bconoboy: blc '' <blc@redhat.com>
21:01:50 <bconoboy> woot new year \o/
21:01:56 * masta is here
21:01:59 <ahs3> .fas ahs3
21:01:59 <zodbot> ahs3: ahs3 'Al Stone' <ahs3@redhat.com>
21:02:58 <hrw> hi
21:03:00 <pwhalen> #topic 1a) Aarch64 - Status Update
21:03:02 <hrw> .fas juszkiewicz
21:03:03 <zodbot> hrw: hrw 'Marcin Juszkiewicz' <mjuszkiewicz@redhat.com>
21:03:24 <pbrobinson> things are building... not particularly automated but we're getting there now
21:03:28 <agreene> .fas agreene
21:03:28 <zodbot> agreene: tag4fedora 'Tim Greene' <tagreene@flowserve.com> - agreene 'Andrew Greene' <andrew.greene@senecacollege.ca>
21:03:32 <handsome_pirate> Ahoy, me hearties
21:03:38 <handsome_pirate> .fas jdulaney
21:03:39 <zodbot> handsome_pirate: jdulaney 'John Dulaney' <j_dulaney@live.com>
21:03:56 <bconoboy> pbrobinson: what're you big pain points on aarch64?
21:03:59 <ahs3> R
21:04:03 <pbrobinson> it's a bit early to start reporting problem packages as otherwise I'll be reporting a lot
21:04:25 <pbrobinson> yes R, ghc and a bunch of other languages
21:04:30 <hrw> pbrobinson: can you survive without mariadb for some time?
21:04:35 <pbrobinson> nope
21:04:37 <bconoboy> #info koji builds are running now- pbrobinson driving builds
21:05:05 <pbrobinson> hrw: it's a core dependency that half the world links to from ldap to logging platforms
21:05:08 <masta> soon I'm going to be joining pbrobinson in the effort to build
21:05:12 <hrw> pbrobinson: tests need to be checked as some of them fail
21:05:36 <hrw> DEBUG: Completed: Failed 3/2149 tests, 99.86% were successful.
21:05:36 <hrw> DEBUG: Failing test(s): main.gis-precise perfschema.func_file_io perfschema.func_mutex
21:06:13 <hrw> I have mariadb in my 'need to fix' queue
21:06:22 <pbrobinson> yep and we have a number of other packages that are similar that I've temporarily disabled tests for
21:06:28 <handsome_pirate> pbrobinson:  I point you to https://ghc.haskell.org/trac/ghc/ticket/7942 for ghc
21:06:32 <pbrobinson> but ultimately they need to be fixed
21:06:38 <handsome_pirate> pbrobinson:  Looks like there is some movement there
21:07:00 <hrw> pbrobinson: sqlite, ruby?
21:07:04 <bconoboy> #info Numerous bugs being worked through- mariadb is pressing
21:08:02 <pbrobinson> hrw: I've been working with the maintainers on ruby, sqlite should be fixed in the next release and it's currently got the same status of the non x86 platforms
21:08:25 <hrw> yay!
21:08:30 <jcapik> .fas jcapik
21:08:31 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
21:08:40 <pbrobinson> there's a bunch of other things that I'm slowly working through and unbundling various circular dependencies
21:08:42 <hrw> ruby failed in one test iirc
21:08:47 <bconoboy> I'll add that we're going to be putting in a few more builders in near term, so we should have plenty of build power as chunks get unlocked
21:08:53 <pbrobinson> hrw: it's currently failing on mainline too
21:08:54 <bconoboy> #info More builders being added this month
21:09:08 <masta> handsome_pirate: good to see them updating the ticket
21:09:39 <pbrobinson> so at the moment the status can be currently summed up as moving forward but it's some what rough around the edges and a number of issues which are being chased etc
21:09:47 <pwhalen> can we disable those tests for mariadb?
21:09:57 <hrw> bconoboy: so my own builds will have more power as I hack on fedora builder machine (or rather fedora build is on same as I was first there)
21:09:58 <pbrobinson> we're hoping to kick off the nightly rawhide composes RSN
21:10:44 <pbrobinson> so what's being done and how will start to be more public and hopefully synced out to the secondary mirrors
21:10:51 <bconoboy> who is in charge of setting up nightly composes?
21:10:57 <bconoboy> dgilmore? masta?
21:11:05 <pbrobinson> dgilmore and myself
21:11:06 <masta> pwhalen: we could put the test in a conditional block, in the aarch64 case have '|true' on the end of the line
21:11:16 <pbrobinson> It's mostly ready to go
21:11:29 <pbrobinson> I just need to clean up a few bits to actually make them almost useful
21:11:59 <pbrobinson> as it's a bit fugly in places
21:12:35 <pbrobinson> but that's about it at the moment
21:12:51 <pwhalen> anything else aarch64, problem packages seem covered ..
21:12:58 <pbrobinson> nope
21:12:59 <masta> yeah it would copy most of the existing setup for armv7 for rawhide nightly, i would imagine
21:13:09 <pbrobinson> I'll send out things to the list as they become more useful
21:13:16 <pwhalen> thanks pbrobinson
21:13:27 <pwhalen> #topic 2a) F21 - Hardware Support Goals
21:13:33 <hrw> I will send qt5 patches to bugzilla soon.
21:13:53 <hrw> not usable for rawhide/aarch64 now as there is huge set of bdeps not there yet
21:14:11 <pbrobinson> well HW support is really not worth discussing IMO until we know what is going to land for 3.14
21:14:39 <pbrobinson> the plan is basically what we have for F-20
21:14:43 <bconoboy> what's landing in 3.13?
21:14:54 <pbrobinson> nothing much over what we have in 3.12
21:15:00 <pbrobinson> improved i.mx
21:15:07 <hrw> still no exynos-mp?
21:15:18 <pbrobinson> improved am33xx
21:15:19 <pbrobinson> hrw: nope, not even in 3.14
21:15:25 <handsome_pirate> lpae is fixed on exynos5
21:15:26 <hrw> samsung...
21:15:30 <handsome_pirate> in 3.13
21:15:31 <pbrobinson> I've  heard rumours of not before 3.16
21:15:35 <bconoboy> utilite mmc in 3.13?
21:15:53 <pbrobinson> handsome_pirate: there is no MP support for any samsung platform
21:16:07 <handsome_pirate> pbrobinson:  I know
21:16:17 <pbrobinson> handsome_pirate: and it won't supported in fedora until then so it's a complete mute point
21:16:22 <handsome_pirate> pbrobinson:  lpae was broken, though, now it's fixed
21:16:42 <pbrobinson> handsome_pirate: still completely irrelevant for this discussion
21:17:16 <pbrobinson> the improvements in 3.13 are primarily improvements on what we have already
21:17:44 <hrw> so before 3.14-rc1 nothing new
21:17:48 <pbrobinson> 3.14 is looking like it will add allwinner support
21:17:56 <pbrobinson> workable allwinner support
21:18:07 <masta> I suspect more i.mx6 boards to turn up, but not too confident about the DTB's going upstream... so more of the same likely
21:18:27 <pbrobinson> the ZYNQ stuff might be working but I've not had anyone test it. jcm said he would as he has HW but I've not heard
21:18:39 <bconoboy> F20 beaglebone black/white were console and questionable, where are with with 3.12/3.13 on those?
21:19:06 <pbrobinson> it's possible, but not guaranteed, that there will be .imx6 HDMI support for 3.14
21:19:35 <pbrobinson> 3.12 on BBB is really good, or will be when 3.12.7 lands
21:20:03 <pbrobinson> 3.13 for BBB I believe we'll be mostly upstream, there'll be a few minor patches
21:20:11 <bconoboy> video?
21:20:31 <pbrobinson> basic modesetting is in place already in 3.12, as is usb
21:20:38 <bconoboy> #info 3.13 kernel feature set is similar to 3.12, no new hardware specifically tested yet
21:20:45 <pbrobinson> 3.12.7 will make the ethernet stable
21:20:49 <handsome_pirate> cpu freq for BBB?
21:20:55 <bconoboy> #info Note to BBB users: 3.12 kernel will make BBB video work
21:21:02 <bconoboy> #undo
21:21:02 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2c1411d0>
21:21:05 <pbrobinson> handsome_pirate: not in 3.12
21:21:07 <bconoboy> #info Note to BBB users: 3.12 kernel will make BBB video work on F20 release
21:21:17 <pbrobinson> handsome_pirate: but I don't see that as critical
21:21:32 <pbrobinson> #info 3.12.7 will be the one to go with
21:21:35 <handsome_pirate> pbrobinson:  No, but it makes life better
21:21:58 <bconoboy> dgilmore: any special uboot plans in F21?
21:22:21 <pbrobinson> handsome_pirate: it needs a generic cpufreq driver which doesn't have all the bits upstream and hence it's not critical
21:23:07 <ctyler> (greg k-h is right, it's past time that arm silicon vendors start landing support *before* they ship)
21:23:08 <pbrobinson> there might be basic support for the rockchips in 3.13
21:23:42 <pbrobinson> ctyler: and can I have a unicorn from the easter bunny please....?
21:24:16 * bconoboy adds unicorn to pbrobinson shopping list
21:24:23 <ctyler> it's not unreasonable. If you're booting a sim, you should be upstreaming.
21:24:36 <bconoboy> can't be solved here guys
21:24:38 <masta> I've seen him posting about distro env configs, and creating fedora logs in the u-boot frame buffer
21:24:52 <pbrobinson> ctyler: I never said it wasn't reasonable but ultimately we need to live in the hear and now and work with what we have......
21:24:56 <masta> s/logs/logos/
21:25:05 <bconoboy> My wish list for F21 is images that can be written and booted without weird post-write fixups.
21:25:19 <masta> +1 bconoboy
21:25:20 <bconoboy> And to stop doing separate vfat images
21:25:33 <jwb> my wish list is to have 64-bit hardware.  GETONIT
21:25:43 <bconoboy> jwb: more hardware is coming this week
21:25:45 <pbrobinson> jwb: we do in koji
21:25:48 <masta> +1 jwb
21:26:06 <pbrobinson> jwb: and the last gcc build on it built 30 mins faster than x86_64
21:26:17 <pwhalen> impressive
21:26:23 <jwb> excellent.  then i extend my wish list to stop supporting 32-bit
21:26:23 <ctyler> +1 bconoboy and jwb, but the unicorns are flying fast and furious today
21:26:24 <jwb> ;)
21:26:44 <bconoboy> we'll eventually use aarch64 hosts for armv7hl builders
21:26:45 <hrw> I want aarch64 desktop on my desk in 1H2014
21:27:00 <bconoboy> so you'll see that nice speed on armv7hl builds.
21:27:08 <pbrobinson> can we please keep the meeting on track.... I would like to have dinner before 10pm
21:27:19 <bconoboy> anything else for f21 wishlist?
21:27:21 <hrw> bconoboy: the day we do it will be end of armv7 hw in build farm
21:27:28 <hrw> bconoboy: ponies?
21:27:34 <bconoboy> pwhalen: let's go :-)
21:27:34 <pwhalen> #topic 2b) F21 - Installation Images
21:27:49 <pbrobinson> hrw: I have two horses... don't need ponies
21:27:50 <jcapik> pbrobinson: and I'd like to go to bed before midnight
21:28:19 <bconoboy> pwhalen: what's the topic about?
21:28:29 <pbrobinson> I was about to ask the same
21:28:33 <pwhalen> I made a net install image for the wandboard for f20, do we want to do more of that type of thing for f21?
21:28:56 <pbrobinson> why do we need board specific install images?
21:28:59 <pwhalen> er, blc you requested it
21:29:04 <jwb> er
21:29:04 <dgilmore> pwhalen: i want to have pungi/lorax make installer images
21:29:06 <bconoboy> pwhalen: Oh, this :-)
21:29:13 <jwb> sorry, i had a question on HW support still
21:29:15 <pwhalen> we dont.. just an example
21:29:19 <bconoboy> Right, so I think the question is how far can we take anaconda installation on boards in F21
21:29:25 <pbrobinson> jwb: sure
21:29:32 <bconoboy> Like can we abandon disk images and just use anaconda
21:29:44 <jwb> have you all seen hans' allwinner proposal on the kernel list?
21:29:49 <dgilmore> bconoboy: I doubt we can
21:29:55 <bconoboy> jwb: no- pointer?
21:30:04 <pbrobinson> jwb: I'm aware of it, I've not read it all and I need to reply to properly clarify
21:30:09 <dgilmore> bconoboy: but i want to move more towards installing not using precanned images
21:30:18 <bconoboy> dgilmore: y, me too
21:30:21 <pbrobinson> jwb: I'll try and get to it tomorrow for you
21:30:24 <pwhalen> dgilmore, +1
21:30:26 <dgilmore> jwb: ive seen his proposal
21:30:32 <jwb> bconoboy, https://lists.fedoraproject.org/pipermail/kernel/2013-December/004752.html
21:30:42 <jwb> pbrobinson, your name is on the Change page...
21:30:43 <dgilmore> jwb: ive not looked to see where we stand u-boot wise
21:30:52 <dgilmore> I dont think there is upstream u-boot support
21:31:00 <masta> jwb: is the allwinner stuff even likely to go upstream, Hans wanted to carry patches... I was wondering if they are ACKed and those kind of nice things?
21:31:01 <pbrobinson> jwb: correct, the discussion I had with him was that it had to be upstream
21:31:20 <jwb> masta, according to Hans, most of it will land in 3.14
21:31:20 <dgilmore> jwb: i think its a win, there is a lot of cheap decent allwinner hardware out tehre
21:31:21 <pbrobinson> jwb: so I'm not sure what or why or how he's deviating from that
21:31:55 <dgilmore> pbrobinson: that he wants to get it in fedora as its headed upstream
21:31:59 <pbrobinson> dgilmore: the support should mostly be there in 2014.01 and better by 2014.004
21:32:00 <dgilmore> test early and often
21:32:04 <jwb> ok, so my question is basically if you as a SIG are comfortable with that because nobody other than Hans chimed in on the thread.  maybe you guys should discuss and reply on the thread?
21:32:26 <pbrobinson> jwb: that's what I was planning but I've just not had the time
21:32:33 <jwb> ok.  still a couple weeks out anyway
21:32:36 <dgilmore> jwb: for me it got lost in holiday breakness
21:32:48 <bconoboy> #link Hans' proposed kernel patch plan needs attention https://lists.fedoraproject.org/pipermail/kernel/2013-December/004752.html
21:32:49 <masta> jwb: I'll respond to his thread =)
21:33:07 <pbrobinson> jwb: from reading some of the upstream landing bits today while on a conf call I think most of it should be landing to give us usb/serial/sata/mmc/ethernet plus deps
21:33:51 <pbrobinson> screen and other bits likely not
21:34:58 <hrw> and a20 is easiest to get virtualization platform with kind-of fedora support
21:35:18 <jwb> hrw, yeah.  that's why i was more open to it
21:35:18 <bconoboy> pwhalen: next?
21:35:32 <jwb> apparently the virt people are all using it or something
21:35:46 <pwhalen> thats all...
21:35:47 <pwhalen> #topic 4) Open Floor
21:35:49 <hrw> jwb: I do not know other platform with such good support
21:36:00 <handsome_pirate> I do have a quick topic
21:36:04 <pbrobinson> jwb: yes
21:36:29 <handsome_pirate> Tomorrow, there will be a meeting to discuss QA tooldevelopment:
21:36:30 <handsome_pirate> https://lists.fedoraproject.org/pipermail/qa-devel/2014-January/000599.html
21:37:20 <pbrobinson> what is the relevance or what do we need to discuss
21:37:23 <handsome_pirate> One thing that would be cool would be for people to start thinking about tasks that they'd like to run against builds coming out of Koji
21:37:38 <handsome_pirate> pbrobinson:  Mostly, this is a heads up
21:37:55 <handsome_pirate> Since ARM is primary, taskotron will have to take arm into account
21:37:57 <hrw> handsome_pirate: first one which came to my mind: Are resulting packages installable
21:37:59 <pbrobinson> I don't see we should be any different to any other primary arch
21:38:01 <dgilmore> handsome_pirate: i have a huge list of things, nothing to do with arm
21:38:08 <handsome_pirate> hrw:  Working on that already
21:38:17 <dgilmore> handsome_pirate: i really dont think there is much arm specific
21:38:28 <handsome_pirate> dgilmore:  It was largely an fyi
21:38:38 <pbrobinson> there's a whole bunch of useful things but none should be arm specific
21:38:39 <hrw> handsome_pirate: I feel too many packages built into not installable state. but thats mostly on aarch64
21:38:55 <handsome_pirate> hrw:  Like I said, working on that
21:39:06 <hrw> handsome_pirate: great
21:39:13 <bconoboy> any other topics?
21:39:20 <dgilmore> ABI checks, rpmdiff checks. there is a ton that can be done
21:39:29 <handsome_pirate> Indeed
21:39:31 <pbrobinson> soname bumps
21:39:39 <dgilmore> right
21:39:52 <pwhalen> going once...
21:40:08 <dgilmore> pwhalen: we didnt really finish the installer question
21:40:25 <bconoboy> dgilmore: have anything to add?
21:40:28 <pwhalen> we didnt.. we can go back
21:40:43 <dgilmore> I dont see disk images going away, they are kinda analogus to livecds
21:41:07 <bconoboy> the way they work is a pain- you can't write and use them which is what end users are expecting.
21:41:09 <dgilmore> but we should maybe work closer with the spin owners to take them over
21:41:33 <dgilmore> bconoboy: in what way?
21:41:45 <bconoboy> dgilmore: adding uboot bits
21:41:56 <dgilmore> bconoboy: we need to work on tooling for that
21:42:08 <dgilmore> bconoboy: so i guess the question is
21:42:18 <bconoboy> dgilmore: agree, but not clear on what the end result is that you'd support getting us to :-)
21:42:34 <dgilmore> most distros make only a minimal image and make images precanned for a bunch of hardware
21:42:35 <handsome_pirate> How are we getting read of fat partition?
21:42:41 <handsome_pirate> Doesn't BBB require that?
21:43:01 <bconoboy> I think we should get rid of the images without a fat partition.
21:43:01 <dgilmore> we make generic images that need some tweaking but get to offer many different types of images
21:43:12 <dgilmore> handsome_pirate: bbb has no requirement for fat
21:43:39 <dgilmore> bconoboy: i think we should get rid of teh images with a fat partition
21:43:42 <hrw> dgilmore: omap3/am in-cpu bootloader does not know !vfat iirc
21:43:49 <bconoboy> we could provide 2 images- One OS image, One (tiny) board specific image- end users download both, write the first, then the second, to the same block device.
21:44:05 <dgilmore> hrw: u-boot on the bbb is on fat on internal storage
21:44:23 <dgilmore> you dont need vfat on microsd
21:44:27 <pbrobinson> ultimately the major reason for the vfat images is for the devices people may wish to use which either a) don't ship with a sane uboot b) we don't ship and build a uboot
21:44:31 <dgilmore> and MLO can be read raw
21:44:31 <hrw> dgilmore: ok. but bbw has only microsd
21:44:42 <bconoboy> dgilmore: removing vfat will artificially keep fedora out of future boards which require it
21:44:44 <dgilmore> teach the MLO ext and you dont need fat
21:44:58 <dgilmore> bconoboy: if future boards require it they are broken
21:45:11 <dgilmore> hrw: its fixable
21:45:17 <ctyler> +1 dgilmore
21:45:17 <hrw> ok
21:45:21 * hrw off
21:45:36 <hrw> 22:44
21:45:40 <bconoboy> dgilmore: uh, calling things broken because they're not how we want them isn't entirely accurate
21:45:47 <pbrobinson> bconoboy: hans is planning on extending his script to support writing out auto configs like on his remix
21:45:59 <dgilmore> bconoboy: sure it is, anaconda cant do vfat
21:46:13 <jcapik> bconoboy: +1
21:46:27 <dgilmore> bconoboy: so if it doesnt work like a regular linux system anaconda cant install it
21:46:37 <dgilmore> and we cant support it
21:46:39 <bconoboy> if we do disk image pairs we can separate the partitions/fs decision on a per-board basis
21:47:12 <bconoboy> One minimal image, one xfce image, etc
21:47:27 <bconoboy> then one trimslice image (ext4), one bbb image (vfat), etc
21:47:31 <dgilmore> bconoboy: to get ahead we need to pick one thing and go with it, we dont have the tools or manpower to do anything else
21:47:59 <dgilmore> bconoboy: not sure what your getting at there
21:48:15 <bconoboy> dgilmore: a different way of handling the issue that lets people write disk images and boot without mounting and copying files.
21:48:34 <pbrobinson> I think there needs to be a proposal sent to the list and it discussed there.... we're just going around in circle here
21:48:41 <bconoboy> +1
21:48:43 <dgilmore> bconoboy: i can not picture what you are trying to describe
21:48:50 <bconoboy> dgilmore: I'll mail the list
21:48:57 <dgilmore> bconoboy: perfect
21:49:21 <pwhalen> ok, anything else left or can pbrobinson eat dinner ?
21:49:32 <dgilmore> lets wrap it up
21:49:57 <pwhalen> #endmeeting