21:00:17 #startmeeting Fedora ARM weekly status meeting 21:00:17 Meeting started Wed Mar 6 21:00:17 2013 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:17 #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore 21:00:17 Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen 21:00:24 .fas pwhalen 21:00:25 * pbrobinson waves 21:00:25 pwhalen: pwhalen 'Paul Whalen' 21:00:41 * masta is here 21:00:44 .fas2 hris@tylers.info 21:00:52 .fas jonmasters 21:00:53 jonmasters: jcm 'Jon Masters' 21:00:59 .fas hris@tylers.info 21:00:59 ctyler: ctyler 'Chris Tyler' 21:01:00 * nirik is lurking around. 21:01:07 * ctyler waves from HK 21:01:09 * j_dulaney is here for a short time 21:01:22 ctyler: I won't make breakfast, juggling sleep and debug time. Tomorrow instead :) 21:01:47 excuses excuses ;-) 21:01:48 * j_dulaney wishes he was in HK 21:01:49 jonmasters: sold 21:01:56 .fas blc@ 21:01:57 bconoboy: blc '' 21:01:59 * j_dulaney needs to get out more 21:02:10 pbrobinson: I have a vexpress local build here I am looking at btw 21:02:12 #topic 0) Status of ACTION items from our previous meeting 21:02:20 ok, let's go 21:02:22 #info Meeting Minutes from last week: 21:02:23 #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-02-27/fedora-meeting-1.2013-02-27-21.00.html 21:02:35 #info bconoboy COMPLETE - list of packages needing aarch64-specific configurey updates. Email sent to the mailing list today, initial package list: 21:02:35 #link http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs 21:02:35 * pbrobinson hasn't completed the vboot review 21:02:53 #info jonmasters COMPLETE - pbrobinson to apply jonmasters' mongodb patch. Failed to build - dmarlin investigating 21:03:04 #info pbrobsinson INPROGRESS - review vboot by the end of the weekend 21:03:18 .fas jcapik 21:03:19 jcapik: jcapik 'Jaromír Cápík' 21:03:20 * jonmasters hasn't filed a bug with LLVM but has raised the issue with folks. I will file a bug and send a link 21:03:45 * jsmith apologizes for being late to the meeting 21:04:21 #action jonmasters to file LLVM bug and send link to the mailing list 21:04:35 anything else from last meeting? 21:05:08 what is up with a15 kernel support? 21:05:30 masta, added to the agenda, we'll come back to it 21:05:35 masta: I have asked dmarlin to start working on that and to co-ordinate with Peter 21:05:41 ok, come back to it 21:05:41 * masta nods 21:05:55 next? 21:05:56 #topic 1) Problem Packages 21:06:18 masta: see meeting notes from last week about a15 from memory. Coming in 3.9 21:06:57 tog-pegasus (sp?), java 21:07:04 eclipse problem is closed! 21:07:24 woot 21:07:28 yah! 21:07:39 there is no bz for either top-pegasus or java is there? 21:08:23 nope 21:08:26 pbrobinson: Are we essentially done mass rebuilding at this point? 21:08:38 #info top-pegasus and java are the biggest blockers right now 21:08:49 the tog-pegasus is a new one and I'm still investigating 21:08:50 #info java team is working on java 21:08:59 I'm also investigating top-pegasus 21:09:09 #action pbrobinson/bconoboy investigating top-pegasus 21:09:14 any other blockers? 21:09:31 I think we're mostly done with the mass rebuild, there will be some stragglers and we've not managed to have a full koji-shadow run yet 21:09:46 #info rawhide statistics: {'older': 2008, 'local_only': 2, 'remote_only': 262, 'same': 10919, 'newer': 2, 'total_missing_builds': 2821} 21:10:03 #info mass rebuild more-or-less done, but koji-shadow has not run to completion yet 21:10:13 but at the moment there's no other major blockers. There's some random kde package issues which I'm working with kde guys on but they're not blocking other packages 21:10:42 is koji-shadow still crashing? 21:11:07 brb 21:11:17 well it falls over but that's SOP. We're getting there 21:11:26 what if it weren't SOP? 21:11:33 standard operating procedure 21:11:38 bah 21:11:41 yeah, I mean, what if it were not? 21:11:52 IE, should we be trying to fix it? 21:12:03 I live to hope really but it's been like that for 2+ years that I've been running it 21:13:05 next? 21:13:19 #info Python hackers welcome to work on koji-shadow stability 21:13:27 next 21:13:50 #topic 2) Aarch64 patching 21:14:38 Thousands of packages need patching 21:15:02 #link http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs 21:15:15 We've kept the discussion local to fedora-arm to date while we get a plan together 21:15:47 wow 21:15:54 that is a big list 21:15:59 we're pushing it for f19 with branching happening in less than a week, this should have happened weeks ago 21:16:00 That list is big, but it's not even complete. There are more 21:16:22 It was supposed to happen before the mass rebuild but dgilmore didn't like the way the script that generated the patches worked, so here we are 21:16:33 and once we branch we'll have to do it twice 21:16:43 Ouch 21:16:45 what kind of patching are we talking about? adding a triplet to Makefiles or more complex? 21:16:50 yes, but the mass rebuild happened weeks ago 21:17:02 masta: it's basically putting the latest config.guess and config.sub in place 21:17:20 bconoboy: the script didnt work in the git tree at all 21:17:20 and we don't even know what needs to be done outside of automake builds 21:17:21 * j_dulaney wonders if we could request a second mass rebuild 21:17:28 bconoboy: so not realyl patching, but adding or replacing a few files? 21:17:34 Yes, it really shoudl have happened weeks ago, but it didn't, so here we are. How do we want to handle this? 21:17:35 bconoboy: and needed to be completely re-written to do the right thing 21:17:42 j_dulaney: for f20 yes.. not f19 21:18:08 bconoboy: we still need to know exactly what packages we are looking at 21:18:08 autoconf builds are the lion's share of the problem 21:18:25 dgilmore: we know at least ~2000 of them with certainty. 21:18:32 I almost wonder if we should even bother with f19 on aarch64, then 21:18:33 bconoboy: no we dont 21:18:34 we'll do what we can, and it'll be great to have this script in place for F20 21:18:47 bconoboy: ive not seen a list of effected packages 21:18:53 dgilmore: I posted it a few hours ago 21:18:55 j_dulaney: we'll do F19, it'll be more painful, but we'll do it 21:18:59 dgilmoare: Scroll up 21:19:01 bconoboy: not seen it 21:19:05 bconoboy: you mentioned last week that it wasn't known what other make platforms were affected 21:19:19 scons, for instance? 21:19:32 cmake... qmake... etc 21:19:33 cmake is widely used 21:19:35 * jonmasters will ask around about non-autotools platforms 21:19:41 pbrobinson: autoconf is the most popular configuration tool, so I'm quite confident in saying that we take care of the lion's share of the problem by handling autoconf 21:19:47 jonmasters: you said that 2 weeks ago :-) 21:19:57 jonmasters: you said you were going to do that all the way back at FOSDEM when I bought it up 21:20:12 pbrobinson: I did talk to Riku about it 21:20:20 * j_dulaney can expiriment with non-autotools and report to the list 21:20:24 when I say "ask" I think what I mean is "raise it as a concern" 21:20:24 dgilmore: fyi, http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs 21:20:32 bconoboy: that might be the case but the fact is we don't know what the situation is so I don't believe you can say that 21:20:40 I suspect we get to figure out how to fix this 21:21:23 jonmasters: both debian and suse have build 6K odd packages, what the hell did they do? 21:21:38 this is a lot of thrash and churn for packages.... are we going to force package owners to do this, or do they have opt-out, perhaps we go unilateral and a proven packager does the deed? 21:22:26 masta: that's the question 21:22:43 We can provide patches today for all the autoconf-using packages 21:22:56 If we just let packagers handle it, then it will never be completed 21:23:01 * j_dulaney says do a mis 21:23:04 mix 21:23:13 At first, individual packagers 21:23:13 bconoboy: jonmasters: what did debian and opensuse do? 21:23:21 when does this need to be done by? whats the timeframe/pressure? 21:23:22 At LCA13 there was a discussion about aarch64 problem packages yesterday, including things that have no support and not necessarily due to autoconf or asm issues. Notes at http://pad.linaro.org/AArch64-porting-effort-moving-from-essential-software-to-important-software if they're useful. In particular, most of the hipster languages are broken. 21:23:25 pbrobinson: details elsewhere 21:23:26 Then have a proven packager go in and finish the job 21:23:32 bconoboy: jonmasters: they must have had the same problems so what was done there? 21:23:37 nirik: It would be nice to have it done before f19 branches. 21:23:58 When systemd landed, most individual packagers couldn't be bothered to do the sysv -> systemd transition 21:24:00 pbrobinson: Afraid I'm not plugged in on those communities. 21:24:09 Viking-Ice did much of that himself 21:24:25 j_dulaney: Yes, leaving it to individual packagers is unlikely to result in prompt result 21:24:28 ctyler: yea, but it didn't cover the topic of non-autotools 21:24:39 so it's planned to build f19 for aarch64? 21:24:47 masta: no opt out and I will do what needs doing 21:24:54 bconoboy: but we are through the Linaro community and have resources there and jonmasters is involved on various committees so we do have connections 21:25:29 pbrobinson: I doubt it's a secret, I just can't answer it myself. Are you asking because you think we should adopt whatever one of them did? 21:25:41 At the least, push to get crit path done by packagers, as well as responsive upstreams 21:25:55 hence the reason I was asking jonmasters as well but he hasn't responded 21:26:10 dgilmore: let me know if you want any help 21:26:18 for the package numbers, I can talk through what the other communities did, but then I would have to elaborate as to why I think we should have a different plan, and then I would have to go into hardware timeframes, and I can talk about all of that here, sorry 21:26:30 pbrobinson: I specifically haven't responded. We can talk, just not here, sorry 21:26:50 bconoboy: I'm asking because I'm wondering what they did, how they went about it and having done it how it can be of use to us to make our lives easier 21:26:58 Regardless of what other distros have done, what we do in fedora basically falls into 3 camps: 21:27:03 sure, we can leverage their experiences 21:27:04 j_dulaney: it's hard to get packagers to care too deeply about a platform that doesn't exist yet and for which the emulation is painfully slow and a slight pita to set up 21:27:06 pbrobinson: +1 21:27:09 1. We wait for the package to automatically move to the latest autoconf via upstream 21:27:16 2. We have the packager make the change 21:27:20 so if we can't talk I don't see what there is to discuss 21:27:23 3. We have a proven packager make the change 21:27:41 bconoboy: 3 is on a proven packager 21:27:44 I think we can keep the conversation to patching of packages. I would prefer we not talk about timing of builds here today 21:27:48 bconoboy: 3 is releng does it 21:27:50 1 will never happy to many packages. ;) Unless there's a reason most upstreams don't switch that very often. 21:27:52 as we mentioned last week we need all the information not parts of it because we don't want a fucking big mess to clean up right before we branch 21:28:06 Doing a combination of all 3 is totally germane, I'm just none of the 3 so I can't dictate terms 21:28:24 jonmasters: all we're talking about is patching 21:28:25 * j_dulaney is +1 all three 21:28:45 jonmasters: I couldn't give a shit about the time of builds, I never mentioned it. I was asking what has been done by the other projects that already have releases out 21:29:13 pbrobinson: We have a mess now- isn't cleaning up the autoconf portion of it worth doing? I don't see why we should wait for the totality of all make systems before taking any action. 21:29:49 dgilmore: Okay, #3 is releng, which in my mind means you :-) 21:30:14 How confident are we that this process is other-platform-safe? If so, what's the concern? 21:30:18 yes, but not 5 days before we branch for release with a half arsed patch that's not well tested and may fuck up a whole lot of shit that proven packagers like myself will end up having to clean up 21:30:29 alright how about we knock out the easy autoconf packages first, and we continue searching for packages that need poking? 21:30:36 this should have been done weeks/months ago 21:31:06 yes, it should have been done earlier. do you mean to say it shouldn't be done now because of that? 21:31:08 masta: I don't see the point in doing half of them because half a distribution is useless 21:31:08 pbrobinson: sorry, I thought you were grumbling as to how they got $number of builds done, understand your question now 21:31:19 pbrobinson: does it make any sense to wait to after branching? is this an all-or-nothing kind of situation? 21:31:44 masta: its a lot easier before branching 21:32:01 pbrobinson: much of the core distirbution is autoconf based- the patch is very low risk. Does that risk need to be quantified? 21:32:20 masta: if we do it after branching we have to do it on f19 and rawhide. Twice the work, twice the cleanup for things that break 21:32:21 I don't believe the other distros have automatically patched. I think the most they've done is re-run autotools for individual packages 21:32:46 * j_dulaney thinks we should skip f19 21:33:06 bconoboy: if much of the core distro is autoconf based it could be argued the risk is higher if it goes wrong 21:33:19 Because if crap is fucked up, a lot of that will land on QA (me) 21:33:35 pbrobinson: that's true. what would you need to see to be okay with it? 21:34:01 * j_dulaney needs to go 21:34:03 dgilmore: same question 21:34:06 Peace, y'all 21:34:13 I believe this should be going to FESCo for approval. dgilmore, what are your thoughts? 21:34:32 * jonmasters sent email to Steve McIntyre and Wookey just now. I'll find them in a few hours from now and ask specifically what Debian did for patching 21:34:35 We need a prpopsal before we can go to fesco 21:34:35 pbrobinson: it will need FESCo approval and a releng mini mass rebuild 21:34:48 So what are we proposing to propose? 21:34:48 * masta agrees on FESCo 21:35:20 * nirik notes next fesco meeting is next wed... 21:35:23 we should have more data to enable FESCo to make good decisions 21:35:23 I'm proposing that it gets taken to FESCo as they need to approve that sort of mass rebuild especially this close to branch 21:35:42 I agree 21:35:48 we should prove that it works for a subset of packages 21:36:07 can issue a number of scratch builds, e.g. 100 on PA 21:36:15 yes, we should have a risk assesment 21:36:16 Just because I'm curious, how many of the packages that need to be rebuilt are in the critical-path package set? 21:36:20 jonmasters: yes, that would help FESCo make their decision 21:36:21 next wed will be 1 day after the branching. ;) but we could indeed try and get a vote in ticket. 21:36:24 then provide that to FESCo 21:36:46 Okay, if we're talking to fesco then we're saying this in the context of doing it after branch, right? 21:36:50 jonmasters: I suggest your quick 21:36:52 If we can say it basically has no negative impact in a small (but statistically useful) set of packages, then I think that can make the autotools argument 21:37:08 bconoboy: no, that's fesco's decision 21:37:12 bconoboy: can you and dmarlin_ handle doing the 100 scratch package test today? 21:37:21 bconoboy: sorry, I mean tomorrow your time? 21:37:42 jonmasters: Yeah, probably. Is there a list of critical path packages somewhere we can work with? 21:37:44 they might say it's low risk enough to do it now, they might push it to post branch for rawhide/f20 21:37:57 bconoboy: there is exactly the critical path list 21:38:03 jonmasters: pointer? 21:38:06 pbrobinson: do you have the critical path link handy? 21:38:06 (or anybody, really) 21:38:14 * jonmasters looking 21:38:28 jonmasters: No, there's a script in releng repo to generate it for each release 21:38:38 https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plain&collctn_list=devel 21:38:52 thanks nirik that's what I was thinking of 21:38:58 I'd like to suggest somebody mail the devel list in addition to talking to fesco. 21:39:00 We should also run the BRs for the package set against the unsupported languages list. 21:39:24 ctyler: critical path is pretty free of weird languages 21:39:44 bconoboy: so if you can run the script against that set of pacakges, document which are patched/not-patched, and fire off scratch builds, you would rock 21:39:53 #link Critical path list is https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plain&collctn_list=devel 21:40:18 pbrobinson: Still, there's weird things like doc tools that need ocaml or haskell that block some pretty key pieces. 21:40:31 #action bconoboy and dmarlin to do before/after patchify builds on critical path packages to demonstrate safety 21:40:35 FWIW I don't think Debian were as organized with automated patching, will followup with that info once the guys get my email and we sync here at LC 21:40:51 who wants to mail devel? any objections to doing so? 21:41:02 #action jonmasters to followup with what Debian and OpenSuSE did for automated patching 21:41:24 bconoboy: please don't mail devel@ until there are numbers from scratch builds 21:41:37 bconoboy: no objections but what are you going to email them about? I suggest its well planned and you have the fesco ticket filed first 21:41:44 pbrobinson: +1 21:42:09 we don't particularly need a flame war over this at the moment just as ARM is getting good karma 21:42:09 pbrobinson: An initial "Hey packagers, please update to the latest autoconf for the love of aarch64" 21:42:26 bconoboy: I thought that had been done 21:42:32 has it? 21:42:36 pbrobinson: indeed 21:42:39 If so its effect has been quite small :-( 21:42:58 There are only about 250 packages that recognize aarch64 right now 21:43:22 bconoboy: there should have been bugs filed months ago and even then with direct emails to their inbox I would bet most would have been ignored. Why do you think I fix most of the packages myself 21:43:27 Okay, who is going to write the fesco ticket? 21:43:45 pbrobinson: Too much free time I suppose ;-) 21:43:45 bconoboy: suggest you do 21:43:53 * bconoboy <- bad cop 21:44:07 #action bconoboy to write fesco ticket 21:44:16 anybody want to sanity check it before I send it? 21:44:22 bconoboy: please 21:44:33 okay- ping me after the meeting if so 21:44:37 pwhalen: next 21:44:48 #topic 3) Managing changes in Uboot and boot scripts 21:45:06 I specifically talked with Grant this evening about this 21:45:15 I have an alternative idea to the current proposals 21:45:24 (That's Grant Likely, father of device tree for those wondering) 21:45:34 It is possible to automatically parse the dtb files and extract the physical memory map for various devices 21:45:38 jonmasters: feel free to reply to the list so it hits a wider audience as well 21:45:59 once that is done, we know the range of RAM and we can infer where U-Boot is loaded 21:46:11 so we can then determine load addresses 21:46:28 there is no need in the vast majority of cases to use the "standard" addresses randomly assigned on platforms 21:46:41 jonmasters: which problem are you solving? 21:46:45 most can use the same address, and in most cases it will be automatically determined as the same from parsing the maps 21:47:00 bconoboy: standardizing load addresses, determination thereof 21:47:21 Okay, thanks (We have other parts of the problem to discuss too) 21:47:26 then the question is what else differs from one platform to another 21:47:26 OK, and what about determining which dtb to use? 21:47:44 and whether we should encode other platform info in a new device tree binding 21:47:53 then that platform info would be in the dtb itself 21:48:03 which means we'd see it from within Linux at runtime 21:48:14 (in a standard location in /proc) 21:48:45 I know I'm on the hook for sending thoughts by email, but I only just spoke with Grant a few hours ago 21:48:57 anyway, that's enough from me 21:49:06 Okay, taking a step back, these are the goals I see: 21:49:17 jonmasters: sooner rather than later please so you don't lose or forget it 21:49:20 1. We want to consolidate all the various images into as small a number as possible. DTB helps with this. 21:49:23 pbrobinson: ack 21:49:43 jonmasters: the things we need to work out to use in anconda and other places, kernel add, initramfs addr, dtb addr, actual dtb file, storage type, filesystem to laod from 21:49:46 2. When upgrading or downgrading kernels we want to ensure that the replacement kernel continues to operate 21:49:51 jonmasters: at a quick brain dump 21:49:52 DTB and unified kernel helps with this 21:50:01 dgilmore: yea, +1 21:50:10 3. We want this to happen without user intervention, like on x86 21:50:32 dgilmore: kernel/initramfs/dtb addr can be automatically determined, could add specific entries to dtb for overriding 21:50:56 dgilmore: dtb file name could be in the dtb, along with storage type, filesystem 21:50:59 dgilmore: in fact, all of it 21:51:05 ultimately once we have a unified kernel and a bunch of dtb files we should be able to almost have a single image but how do we automatically determine what is needed to get from a uboot prompt to a booted system with out user intervention 21:51:06 jonmasters: The dtb idea is good, but it doesn't solve the "which dtb do I load at boot?" question 21:51:09 jonmasters: not reallt 21:51:10 So once you're booted with the right dtb, you can find the corresponding one for next time (updates) plus uboot load addresses. 21:51:35 bconoboy: well, if it's in the dtb then at runtime we'd have that info provided we booted at least once 21:51:49 ctyler: right 21:51:50 I think we can write a hush script to determine with some (not complete) accuracy which dtb to load based on the uboot environment 21:52:08 This may be a dumb question, but can the kernel detect the specific device it's running on and choose the dtb accordingly? 21:52:09 jonmasters: That's true for a single system, but not true for an installer image or a canned image. That's the base case we're trying to solve. 21:52:16 Rather like loadable modules? 21:52:33 jonmasters: we need to say we are making for a panda/beagle oh it needs a vfat partition at the start fo the disk 21:52:59 And, if this isn't in the kernel, how difficult would it be to get it there? 21:53:12 j_dulaney: dtb gets loaded before the kernel is booted, unfortunately 21:53:21 Ah 21:53:25 j_dulaney: at best you have uboot's environment to work with 21:53:34 * j_dulaney waves his ignorance around 21:53:39 j_dulaney: the dtb tells the kernel what hardware is attached and where 21:53:46 in many cases uboot itself has a dtb embedded which is really handy 21:53:52 dgilmore: well, train of thought here, but if we had that info in a dtb at least that could be our "lookup" database. If e.g. we knew the platform we were on, we could scan dtbs to match on a new platform name entry in the dtb and get this info in the installer 21:54:30 jonmasters: thats not really feasable 21:54:42 jonmasters: anaconda cant use that for instance 21:55:05 dgilmore: I think we can create the database you want to have, but I'm not sure where to store it. Is it part of grubby? Is it a new package? Is it an extension to the kernel package? 21:55:24 bconoboy: its a new fucking package 21:55:35 it sounds like this needs a lot more thought and discussion that can be solved in a single meeting. How is best we move forward on this as it's clear we won't be able to solve all this now and we're running out of time 21:55:41 bconoboy: its a new libarary that anaconda can import 21:55:45 bconoboy: I'm not sure what the difference is between said database and having something that scans a directory of dtbs containing this info and obtains what is requested 21:56:10 jonmasters: it's the uboot detection bits that you can't get from the dtb 21:56:14 we can write a tool that will make us a boot sdcard for different systems 21:56:20 jonmasters: there's more than the load locations involved here 21:56:38 ctyler: I'm proposing a new binding for devicetree that would have all of the platform info 21:56:58 jonmasters: won't help with existing platforms 21:57:04 (it's a good long term strategy of course) 21:57:09 ctyler: there's no difference when it comes to having something that runs in a Linux userspace environment and I didn't think dgilmore was proposing a library linked into U-Boot as a new database 21:57:11 jonmasters: and i boot something on my trimslcie 21:57:30 jonmasters: how does that get loaded and know im on a trimslice 21:57:31 dgilmore: Okay, new package. Are you going to write it? I can write what I think makes sense, but it may not quite look like what you're thinking of 21:57:43 bconoboy: we support a relatively small number of platforms, so we could fix this properly without a hack and require changes to those platforms 21:57:50 jonmasters: i then put it in my snowball, and it magically works how? 21:58:03 bconoboy: i started on it today 21:58:20 dgilmore: can others join in? 21:58:23 dgilmore: but the database you're asking to write, you're not looking to link that into U-Boot are you? 21:58:29 bconoboy: yes its on fedora-hosted 21:58:36 dgilmore: pointer? 21:58:37 jonmasters: no 21:58:38 dgilmore: you're looking for some database you can use at e.g. image creation time to wire up the right dtb 21:58:39 dgilmore: Where? 21:58:55 https://fedorahosted.org/arm-boot-config/ 21:58:59 jonmasters: No, we want to wire up *all* the dtbs at image ceration time 21:59:04 dgilmore: awesome 21:59:15 #link dgilmore has started a new package, https://fedorahosted.org/arm-boot-config/ 21:59:17 dgilmore: and I'm saying instead of a new database, have a script that obtains this by scanning a directory of dtbs, matching on the platform, and extracts the info from a new binding set of properties 21:59:29 jonmasters: well image creation time to ensure things are right for the platform. 21:59:45 jonmasters: but also for use in a tool to setup a installer sdcard 21:59:57 So the only issue here is whether we stuff this into the dtb or create another file (db) to hold it. 22:00:11 it's not really dtb material is it? 22:00:23 dgilmore: right, so that tool simply scans all of the dtbs (in a directory) and extracts the necessary properties which we have added in a standard way 22:00:35 pwhalen: I think we're almost there 22:00:37 Upside to db is that we can use unmodified upstream dts/dtb. Upside to dtb's is that we don't need a separate db. 22:00:39 jonmasters: no 22:00:46 bconoboy: the dtb describes the platform, this is platform info, it's plausible to add it there 22:01:06 we've got a few more topics, should we move this to #fedora-arm, or the mailing list? 22:01:12 dgilmore: no? no what? 22:01:20 mailing list I believe 22:01:24 pwhalen: well so far my email on it to the list has one reply 22:01:36 so please people reply to that with your thoughts 22:01:53 jonmasters: adding that to the dtb's is a burden we'll be assuming, then, since upstream dtb's won't have that extra data 22:02:20 #action jonmasters to reply to the fedora list with his dtb idea 22:02:58 #topic 4) Arm Koji status update 22:03:34 nirik, do you have an update? 22:03:48 just a quick one... 22:03:53 perfect 22:04:10 things are partially implemented network wise... hopefully done later today. But I've heard that before. 22:04:22 it might end up being 2 /24's instead of 1 /23 22:04:39 #info ARM network almost ready to go for the 3 other chassis 22:04:42 I'll be happy to set things up as soon as it exists. 22:04:52 probibly we should do firmware update on them too. 22:05:10 thats all I had. 22:05:16 thanks 22:06:11 #topic 5) ARM Tech Talks - suggestions for future talks, volunteers? 22:06:21 #info please send any idea 22:06:26 #undo 22:06:26 Removing item from minutes: 22:06:43 nirik: we might even have a new kernel soon 22:06:45 #info please send ideas for future tech talks to the list 22:06:54 I had a suggestion here: you're welcome to use the #fedora-classroom channel for these. ;) It already exists, but isn't all that active these days. 22:07:09 pbrobinson: cool. 22:07:45 nirik, dont see why not 22:08:01 #topic 6) Open floor 22:08:05 on kernel, I'm poking vexpress at the moment, panda I need more time 22:08:22 there's a backtrace we're getting sometimes in omapdss 22:08:23 We'll talk a15 next week perhaps? 22:08:29 pwhalen: sure 22:08:45 * j_dulaney notes to be around for a15 22:08:45 How are we doing on 3.8? Is it ready to push? 22:08:45 pwhalen: I've asked dmarlin to start a first cut kernel-lpae 22:08:46 pwhalen: or A15 on list, I was going to post a 3.9 kernel plans soon 22:08:51 I had a small thing for open floor: 22:09:01 but pbrobinson and dmarlin can sync on that 22:09:25 is there going to be another push to make arm primary? f19? f20? might be good to discuss that again and see what's left that needs doing there. 22:09:27 pbrobinson: I got a running 3.9rc1 on x86; it's failed to build on arm so far 22:09:41 on 3.8 kernel we have 4 issues on my list 1) vexpress divide by zero 2) Panda ES crash on boot 3) beagle usb 4) highbank upgrades 22:10:03 nirik: believe the goal from fudcon was to release f19 simultaneous with PA, then push in f20 22:10:03 nirik: at FUDCon we identified an F20 target 22:10:06 pbrobinson: I am actively debugging the uart (divide by zero) issue - thanks for the regulator changes to vexpress 22:10:13 nirik: the plan is at the moment for F20, we need to get a proposal into FESCo soon. 22:10:21 bconoboy: cool. ok. 22:10:27 pbrobinson: on Panda I have my FS hooked up here, collecting data on the crash on boot but get to it after vexpress 22:10:28 yeah, sooner the better... lead time is good for those discussions. 22:10:41 sounds great 22:10:50 let's ask mlangsdorf to look at the highbank upgrade issue 22:11:00 nirik: yea, we really need to start building straight after branch, dgilmore and I are working on it 22:11:10 it's just a kernel dep but he's offered to help with highbank stuff and he's a smart guy who can figure that out 22:11:37 dgilmore, the spins-kickstars were in the process of being broken to ease our upstreaming of arm kick-starts. im hoping to help get that done this week. so fyi 22:11:40 jonmasters: the way it was done in the past no longer works 22:11:42 jonmasters: highbank upgrade issue is purely a kernel.spec I have that in hand, it's easy 22:11:43 bconoboy: can you check in with Mark later and ask that he look at the kernel dep issue for highbank? This is the new multiplatform kernel obsoleting kernel-highbank 22:11:45 pbrobinson: investigating Arndale CPU lockups, have isolated the spinlock line causing them and working to identify cause of conflict, patch should follow 22:11:55 so we need to test some different things and see what works 22:12:04 pbrobinson: you've got it? ok then let's just get mark lined up to help you test 22:12:06 masta: excellent 22:12:11 ctyler: what kernel, is this mainline or a branch? 22:12:16 jonmasters: why mark when it's an rpm dep issue? 22:12:20 masta: i started the breaking thinsg up process 22:12:22 jonmasters: that's the plan 22:12:24 pbrobinson: it's the 3.4 Google kernel AFAIK 22:12:29 pbrobinson: thanks 22:12:51 bconoboy: just to test it, mark has offered and it's good to leverage - he has lots of highbanks around to run tests on 22:13:07 Exynos5 3.6-3.9 22:13:11 In case anyone is interested in the raspi f18-v6 status, we've built around 11000 source rpms but are missing some big ones like webkitgtk3 22:13:14 pbrobinson: we haven't enabled any exynos support yet have we? 22:13:21 and mesa 22:13:22