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