19:29:55 #startmeeting Fedora ARM weekly status meeting 19:29:55 Meeting started Wed Aug 7 19:29:55 2013 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:29:55 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:29:55 #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore dmarlin masta handsome_pirate msalter ahs3 agreene jcapik ddd_ 19:29:55 Current chairs: agreene ahs3 bconoboy ctyler ddd_ dgilmore dmarlin handsome_pirate jcapik jonmasters masta msalter pbrobinson pwhalen 19:29:59 .fas pwhalen 19:30:00 pwhalen: pwhalen 'Paul Whalen' 19:30:06 .fas dmarlin 19:30:07 .fas blc@ 19:30:09 dmarlin: dmarlin 'David A. Marlin' 19:30:10 good afternoon everyone 19:30:12 bconoboy: blc '' 19:30:21 .fas ahs3 19:30:22 ahs3: ahs3 'Al Stone' 19:31:19 * masta is here 19:31:27 howdy folks 19:31:54 .fas jcapik 19:31:55 jcapik: jcapik 'Jaromír Cápík' 19:32:34 #topic 0) Status of ACTION items from our previous meeting 19:32:34 #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-31/fedora-meeting-1.2013-07-31-19.30.html 19:32:34 #info no ACTION items last week 19:32:57 .fas jcm 19:32:58 jonmasters: jcmoore 'Curt Moore' - jcmartin 'James C Martin' - jcmoralesc 'Juan Morales' - nagarajcm 'Nagaraj' - jcmontero 'Juan Carlos Montero' - jcmannam 'MANNAM JAYACHAND' - yoda 'James Malin' - carlosfranca 'José Carlos Moreira de França' (1 more message) 19:33:13 oh meh, silly bot 19:33:13 not sure if there is anything from last week we wanted to talk about ? 19:33:43 (ARM related) 19:34:07 pwhalen: maybe worth just noting the PA Koji work Dennis did 19:34:33 which is awesome, including the fix for noarch packages, which is now in production 19:35:04 #info ARM in primary koji is up and running well. Tnx dgilmore. 19:35:25 dgilmore will be getting $free beer from me shortly :) 19:35:33 fix for noarch, what was that all about? 19:35:35 (or Starbucks, or whatever he drinks) 19:35:45 masta: the armhfp vs. armv7hl default 19:35:57 ah 19:36:05 * pbrobinson is here 19:36:13 #topic 1) Problem packages 19:36:17 perfect timing! 19:36:24 masta: yea, Koji would not pick up armv7hl for noarch because we never built noarch packages for ARM before :) 19:36:41 hi Peter! 19:37:11 none that I'm aware of... but without koji-shadow (YIPPEE!!!!) This is now my reference http://ausil.fedorapeople.org/f20-failed.html 19:37:32 #link F20 failed build list (not just arm) is at http://ausil.fedorapeople.org/f20-failed.html 19:37:46 and most of them aren't arm 19:38:03 but at the moment I'm not aware of any particular problem packages 19:38:07 * jsmith is here, finally 19:38:08 is that from mass rebuild or any old build failure? 19:38:18 and I've been watching like a hawk for issues 19:38:33 that's the mass rebuild plus any fixes since 19:38:55 the original number was around 1500 failures and it's going downwards 19:39:06 did pandoc get fixed? I know adamw- whoa speak of the devil, was looking for a fix 19:39:37 I've looked and I think it's one for juhp but I think he's off until next week 19:39:42 pandoc is on the failed list 19:39:49 yeah, that's why I'm here 19:39:59 pandoc fails to build on arm, works on x64 and i686, failure is odd and i can't figure it out 19:40:02 #link to pandoc - http://koji.fedoraproject.org/koji/buildinfo?buildID=454666 19:40:27 it's dependent on ghc and I know juhp was looking at some ghc issues for me 19:40:55 he thought he'd fixed them but this might be a remnant of it 19:41:40 some not sure why I have pandoc installed here at all, but hey 19:42:04 adamw: nor do I ;-) 19:42:46 can anyone here have a look at it? 19:43:14 adamw: is it blocking anything in particular or can it wait a few days? 19:43:25 pbrobinson: i just took a quick look at the dep chain, it doesn't look terrible 19:43:39 pandoc-pdf , ghc-hakyll 19:44:05 i only happened to notice it because i have it installed here, but i can't see any particular reason, must be an orphan 19:45:29 any other problem packages to call out here, or shall we move on ? 19:45:49 #topic 2) Kernel Status Update 19:47:12 back to the status quo, after a little hiccup earlier 19:47:56 i'll work on the trimslice networking stuff when i get back from flock 19:48:14 omap still busted, working on getting tools to debug that 19:48:49 thsi is 3.11? 19:48:52 I sent some info to the list as well 19:49:02 yes. 19:49:13 specifically kernel-3.11.0-0.rc4.git1.1.fc20 19:49:32 from the testing pwhalen and others have done, fc19 seems to have no issues with 3.10 19:49:33 #info As of kernel-3.11.0-0.rc4.git1.1.fc20, things are getting better, with a few exceptions 19:49:36 so exynos support is still missing I've heard, what about beagle stuff? 19:49:40 #info trimslice: networking is broken 19:49:51 #info omap: not booting 19:49:56 masta, didnt get to the bone yet 19:50:07 what's confirmed working? highbank and vexpress? 19:50:27 highbank - no issue 19:50:35 #info highbank: working 19:50:52 vexpress hangs when bringing up the gui, serial works fine 19:51:04 #info vepxress: text console okay, gui broken 19:51:05 OMAP I will followup with info on when I get chance - after flock slides :) 19:51:30 back, soory 19:51:31 Any update on exynos, beaglebone, allwinner, etc? 19:51:33 #info getting Kyle a hardware debugger for OMAP 19:51:47 jonmasters: doesn't he have one yet? 19:52:43 anything else for the kernel? 19:52:57 #info exynos, beaglebone, allwinner not tested with latest kernel yet 19:53:02 * jsmith still hasn't had any luck with 3.11 and the Armada processors 19:53:34 jsmith: It's only with the aforementioned kernel rev that anything is working so you might want to retry (There was a system-wide kernel bug until recently) 19:53:35 #topic 3) Aarch64 Status Update 19:53:55 We have 11840/13606 packages built 19:54:03 We're building f19-updates now 19:54:26 #info 11840/13606 packages built for aarch64 19:54:39 The single biggest blocker at this point is kdelibs3, which needs qt, which msalter is working on as he has time 19:55:28 f19 updates are keeping the builder queue full which is nice 19:55:33 * mcpierce is here 19:55:50 Other outstanding blockers are ghc and v8 19:56:23 handsome_pirate is poking at ghc, but it hasn't received much upstream attention 19:56:43 v8 will be fixed in due course 19:57:03 after that the missing packages will just unlock a few dozen builds here and there 19:57:11 So, all in all, things are looking really good. 19:57:34 :-) 19:57:56 My main concern is that we get on to building F20 packages soon before circular bootstrap issues get in the way. 19:59:01 This happens, for instance, when there is an update to an F20 package that changes library versions, then all the other packages update to it, and then updates to those packages deprecate the stepping stone source rpms. 20:00:00 #info qt is biggest package blocker, followed by ghc and v8, everything else blocks only a few dozen packages each 20:00:17 any questions? 20:00:42 so... 20:00:49 #info We need to move to building F20 packages soon before circular dependencies force us to re-bootstrap. 20:01:03 kinda an open floor question, but was going to ask about Koji 20:01:14 because to get on to F20 it makes sense to get Koji up and running 20:01:25 (we can come back to this if you prefer Brendan) 20:01:29 we should do a quick run up for f20 at flock over a beer or similar for aarch64 20:01:43 jonmasters: let's cover at the end 20:02:09 #topic 4) Hardware support in F20 20:02:10 ok 20:02:45 Okay, I think I asked for this topic 20:02:56 :) 20:02:56 We have a relatively small number of supported devices in F19 20:03:07 right 20:03:08 The 3.11 kernel is bringing a lot of new potential territory. 20:03:21 ...and we want to be deliberate in our efforts 20:03:22 I've got a big slide on it for my talk 20:03:32 I've already ventured to support Compulab's upcoming utilite since it's an i.mx6 20:03:48 So I feel I have some personal ownership of that one 20:03:53 and I was planning on meeting up with kylem at Flock to solidify the plans 20:03:57 But there are other devices that we might support 20:04:22 i.MX stuff it looking good 20:04:26 And for any of them, we need to make sure we have coverage in uboot, kernel, graphics if present, and somebody who can test 20:04:37 * dgilmore wants wandboard supported 20:04:37 there the util.... that blc has been communicating with 20:04:44 and the wandboard 20:04:51 dgilmore: Yeah, wandboard makes sense, it's i.mx6 too isn't it? 20:04:59 yep 20:05:05 bconoboy: it is, i have a quad here 20:05:12 and then the Beagle* (bones and xM) 20:05:27 Yeah, so I'd suggest we shoot for good i.mx6 support- we should support boards that have taken the trouble to get their code upstream. 20:05:37 where is rockchip and allwinner in their upstreaming? 20:05:50 There are other devices to consider though- exynos SoCs for instance 20:05:55 Allwinner won't be there I don't think 20:06:02 but RockChips might 20:06:10 exynos should be supportable 20:06:16 yes 20:06:22 i have an older model origenboard 20:06:37 There's still a pile of i.MX code that's not upstream yet 20:06:37 and exynos is on my topic to discuss with kylem 20:06:38 there is some arndales and chromebook 20:06:39 The trick with many of these is that the kernel is upstream, but the uboot isn't 20:06:52 All the CAAM code, for instance 20:06:59 mjg59: yes, we know, but it's still usable 20:07:15 Yeah, for desktop-type purposes it's probably fine 20:07:23 mjg59: right, but it seems they are wrking to get it up, wandboard works headless today just fine 20:07:40 So I suggest the following course of action: 20:07:53 3.12 should have working video from what i can tell 20:07:57 Kyle (arm kernel maintainer) will be at flock, pick his brain on what devices are going to be viable in 3.11 20:08:32 Dgilmore (uboot maintainer) will be at flock, make sure any device that is viable in kernel 3.11 has a uboot we can work with by talking to him 20:09:08 I can provide a limited amount of hardware for these new devices 20:09:28 Is 3.12 going to be in f20 on day 1? 20:10:15 not sure yet... I think it'll be borderline 20:10:25 Okay, let's plan for 3.11 then. 20:10:34 If we can slip additional stuff in at the end of the cycle that's great 20:10:43 the beaglebone folks will hopefully finish their patches so we can have that one ready for f20.... I'd like to have a nice inexpensive board ready by then 20:11:00 masta: that's my plan 20:11:20 speaking of u-boot im working with upstream to try and define a set of standard features and environment for distro support 20:11:59 Let's reconvene on this topic next week after flock. Hopefully kyle/dennis will have worked through the 3.11 kernel/uboot matrix of possibilities 20:12:19 #info Many new boards are possible to support with kernel 3.11 20:12:27 so regarding u-boot... 20:12:48 there are cmds in one u-boot, but not the others, etc.... 20:12:48 #action dgilmore and kylem to put heads together at FLOCK to discuss which boards are viable from kernel/uboot perspective 20:13:08 and me!! 20:13:14 #undo 20:13:14 Removing item from minutes: 20:13:23 #action dgilmore, kylem, pbrobinson to put heads together at FLOCK to discuss which boards are viable from kernel/uboot perspective 20:13:37 bconoboy: better! 20:13:39 we want to get with teh other distros and say feature X, Y, and Z need to be configured to have any hope of a distro supporting the board 20:13:47 #action If you are at flock, please join in the discussion 20:14:06 #info We will review this topic next week with results 20:14:09 masta: thats what im trying to do now 20:14:23 dgilmore: I know, just trying to explain to the group 20:14:36 masta/dgilmore: Let's cover that with links and stuff during open floor? 20:14:49 bconoboy: ack 20:14:55 anything else for hw? open floor is next 20:15:02 nope 20:15:03 #topic 5) Open Floor 20:15:44 Okay, uboot standardization: go! 20:16:03 so there are some u-boot features we probably want, and some we need. 20:16:21 #link nb 20:16:29 dgilmore: That didn't seem to work 20:16:31 #link http://lists.denx.de/pipermail/u-boot/2013-August/160080.html 20:16:34 better 20:16:59 #info thread with u-boot upstream on standadising features 20:18:19 dgilmore: that is a pretty sane proposal in the link 20:18:40 so im trying to get to a point where we can simply add new board and they will work 20:19:04 hardware vendors will know what they ned 20:19:06 need 20:19:22 and it gives users a good experience 20:19:30 It would be nice if the other distros would chip in 20:19:36 booting an old kernel is nice and easy 20:19:41 select the option in the menu 20:19:57 bconoboy: it would be and i have poked some of them i know 20:20:56 I think the real emphasis here is that if all the distros do the same thing, it gives uboot vendors some very easy directions to ensure support by all distros- we all win 20:21:10 bconoboy: exactly 20:21:22 ... at the same time, it's not compulsory, so the flexibility uboot provides isn't compromised 20:21:25 the u-boot folks asked us to help them define this list 20:21:35 after Jon's uefi+acpi thing 20:21:47 u-boot did ask us to do so 20:21:57 the discussion has been positive 20:22:05 dgilmore: do you need anything from the rest of the arm team at this point? 20:22:06 there are some take away tasks 20:22:07 so it's not like we are ganging up on them, they asked to a list of minimume supportable features 20:22:34 bconoboy: help in implementing what we want across the board would be good 20:23:01 bconoboy: help working with compulab to enable some of the missing things would be good also 20:23:15 and getting a updated u-boot out of them 20:23:25 what, for trimslice? 20:23:30 bconoboy: yes 20:23:38 bconoboy: having done a-b-c you might be in a good situation to know the various quirks or missing features we might request. 20:23:58 They were going to have an update in june- with the release of the utilite I believe the trimslice is now effectively abandoned. We can provide our own uboot though. 20:24:15 trimslice needs ext4 support, and to additionally try to load a extlinux.conf file 20:24:33 dgilmore: How do you feel about chain loading uboots? 20:24:35 bconoboy: i know we can, just would rather not 20:25:11 #action one thing we need is a script to install various u-boots into sdcards 20:25:22 wouldn't recommend chain loading 20:25:37 hard to know what state you're in, etc. 20:26:00 updating u-boot on trimslice may be easier with nvidias newly released open source tools 20:27:43 dgilmore: I'm happy to relate requests back to compulab, but it would be best if the other distros were saying the same things to them at the same time 20:28:03 bconoboy: indeed, so far they have all been silent 20:28:35 bconoboy: if need be ill build a trimslice update image 20:28:43 Let's ping funkypenguin for suse 20:28:48 I've been trying to reach our friends over in opensuse... they were having their conference in Greece so maybe now is a good time to try again 20:28:49 Who can we ping at canonical? 20:28:57 i really want us to use extlinux.conf everywhere in what we ship for f20 20:29:06 Michael 20:29:24 Michael Casadavell 20:29:36 he's the ARM team lead at Canonical 20:30:03 jonmasters: Send me his email address and I'll ping he and andy 20:30:13 jonmasters: :) sounds like the right guy 20:31:05 bconoboy: michael.casadevall AT canonical DOTNOSPAM com 20:31:10 robie basak at canonical would be another good person to involve (works with arm servers 20:31:12 (email address filtered for archives) 20:32:08 anything else for open floor? 20:32:12 bconoboy: be sure to cc me 20:32:31 pwhalen: just a reminder. test the nightly rawhide images 20:32:34 If you're at Flock, I'd really appreciate your help at the ARM Docs Hackfest :-) 20:33:02 http://koji.fedoraproject.org/koji/tasks?state=all&view=tree&method=appliance&order=-id 20:33:12 #link http://koji.fedoraproject.org/koji/tasks?state=all&view=tree&method=appliance&order=-id 20:33:22 #info link to nightly images 20:33:24 dgilmore, does the latest include rc4-git1? 20:34:43 tnx jcm/etc 20:35:04 #endmeeting