21:00:17 <pwhalen> #startmeeting Fedora ARM weekly status meeting 21:00:17 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:17 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore 21:00:17 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen 21:00:24 <pwhalen> .fas pwhalen 21:00:25 * pbrobinson waves 21:00:25 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com> 21:00:41 * masta is here 21:00:44 <ctyler> .fas2 hris@tylers.info 21:00:52 <jonmasters> .fas jonmasters 21:00:53 <zodbot> jonmasters: jcm 'Jon Masters' <jonathan@jonmasters.org> 21:00:59 <ctyler> .fas hris@tylers.info 21:00:59 <zodbot> ctyler: ctyler 'Chris Tyler' <chris@tylers.info> 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 <jonmasters> ctyler: I won't make breakfast, juggling sleep and debug time. Tomorrow instead :) 21:01:47 <pbrobinson> excuses excuses ;-) 21:01:48 * j_dulaney wishes he was in HK 21:01:49 <ctyler> jonmasters: sold 21:01:56 <bconoboy> .fas blc@ 21:01:57 <zodbot> bconoboy: blc '' <blc@redhat.com> 21:01:59 * j_dulaney needs to get out more 21:02:10 <jonmasters> pbrobinson: I have a vexpress local build here I am looking at btw 21:02:12 <pwhalen> #topic 0) Status of ACTION items from our previous meeting 21:02:20 <jonmasters> ok, let's go 21:02:22 <pwhalen> #info Meeting Minutes from last week: 21:02:23 <pwhalen> #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-02-27/fedora-meeting-1.2013-02-27-21.00.html 21:02:35 <pwhalen> #info bconoboy COMPLETE - list of packages needing aarch64-specific configurey updates. Email sent to the mailing list today, initial package list: 21:02:35 <pwhalen> #link http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs 21:02:35 * pbrobinson hasn't completed the vboot review 21:02:53 <pwhalen> #info jonmasters COMPLETE - pbrobinson to apply jonmasters' mongodb patch. Failed to build - dmarlin investigating 21:03:04 <pwhalen> #info pbrobsinson INPROGRESS - review vboot by the end of the weekend 21:03:18 <jcapik> .fas jcapik 21:03:19 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com> 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 <pwhalen> #action jonmasters to file LLVM bug and send link to the mailing list 21:04:35 <pwhalen> anything else from last meeting? 21:05:08 <masta> what is up with a15 kernel support? 21:05:30 <pwhalen> masta, added to the agenda, we'll come back to it 21:05:35 <jonmasters> masta: I have asked dmarlin to start working on that and to co-ordinate with Peter 21:05:41 <jonmasters> ok, come back to it 21:05:41 * masta nods 21:05:55 <bconoboy> next? 21:05:56 <pwhalen> #topic 1) Problem Packages 21:06:18 <pbrobinson> masta: see meeting notes from last week about a15 from memory. Coming in 3.9 21:06:57 <pbrobinson> tog-pegasus (sp?), java 21:07:04 <pbrobinson> eclipse problem is closed! 21:07:24 <bconoboy> woot 21:07:28 <masta> yah! 21:07:39 <bconoboy> there is no bz for either top-pegasus or java is there? 21:08:23 <pbrobinson> nope 21:08:26 <bconoboy> pbrobinson: Are we essentially done mass rebuilding at this point? 21:08:38 <bconoboy> #info top-pegasus and java are the biggest blockers right now 21:08:49 <pbrobinson> the tog-pegasus is a new one and I'm still investigating 21:08:50 <bconoboy> #info java team is working on java 21:08:59 <bconoboy> I'm also investigating top-pegasus 21:09:09 <bconoboy> #action pbrobinson/bconoboy investigating top-pegasus 21:09:14 <bconoboy> any other blockers? 21:09:31 <pbrobinson> 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 <bconoboy> #info rawhide statistics: {'older': 2008, 'local_only': 2, 'remote_only': 262, 'same': 10919, 'newer': 2, 'total_missing_builds': 2821} 21:10:03 <bconoboy> #info mass rebuild more-or-less done, but koji-shadow has not run to completion yet 21:10:13 <pbrobinson> 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 <bconoboy> is koji-shadow still crashing? 21:11:07 <jonmasters> brb 21:11:17 <pbrobinson> well it falls over but that's SOP. We're getting there 21:11:26 <bconoboy> what if it weren't SOP? 21:11:33 <pbrobinson> standard operating procedure 21:11:38 <pbrobinson> bah 21:11:41 <bconoboy> yeah, I mean, what if it were not? 21:11:52 <bconoboy> IE, should we be trying to fix it? 21:12:03 <pbrobinson> I live to hope really but it's been like that for 2+ years that I've been running it 21:13:05 <pwhalen> next? 21:13:19 <bconoboy> #info Python hackers welcome to work on koji-shadow stability 21:13:27 <bconoboy> next 21:13:50 <pwhalen> #topic 2) Aarch64 patching 21:14:38 <bconoboy> Thousands of packages need patching 21:15:02 <pwhalen> #link http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs 21:15:15 <bconoboy> We've kept the discussion local to fedora-arm to date while we get a plan together 21:15:47 <masta> wow 21:15:54 <masta> that is a big list 21:15:59 <pbrobinson> we're pushing it for f19 with branching happening in less than a week, this should have happened weeks ago 21:16:00 <bconoboy> That list is big, but it's not even complete. There are more 21:16:22 <bconoboy> 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 <pbrobinson> and once we branch we'll have to do it twice 21:16:43 <j_dulaney> Ouch 21:16:45 <masta> what kind of patching are we talking about? adding a triplet to Makefiles or more complex? 21:16:50 <pbrobinson> yes, but the mass rebuild happened weeks ago 21:17:02 <bconoboy> masta: it's basically putting the latest config.guess and config.sub in place 21:17:20 <dgilmore> bconoboy: the script didnt work in the git tree at all 21:17:20 <pbrobinson> 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 <masta> bconoboy: so not realyl patching, but adding or replacing a few files? 21:17:34 <bconoboy> 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 <dgilmore> bconoboy: and needed to be completely re-written to do the right thing 21:17:42 <pbrobinson> j_dulaney: for f20 yes.. not f19 21:18:08 <dgilmore> bconoboy: we still need to know exactly what packages we are looking at 21:18:08 <bconoboy> autoconf builds are the lion's share of the problem 21:18:25 <bconoboy> dgilmore: we know at least ~2000 of them with certainty. 21:18:32 <j_dulaney> I almost wonder if we should even bother with f19 on aarch64, then 21:18:33 <dgilmore> bconoboy: no we dont 21:18:34 <jonmasters> we'll do what we can, and it'll be great to have this script in place for F20 21:18:47 <dgilmore> bconoboy: ive not seen a list of effected packages 21:18:53 <bconoboy> dgilmore: I posted it a few hours ago 21:18:55 <jonmasters> j_dulaney: we'll do F19, it'll be more painful, but we'll do it 21:18:59 <j_dulaney> dgilmoare: Scroll up 21:19:01 <dgilmore> bconoboy: not seen it 21:19:05 <pbrobinson> bconoboy: you mentioned last week that it wasn't known what other make platforms were affected 21:19:19 <j_dulaney> scons, for instance? 21:19:32 <pbrobinson> cmake... qmake... etc 21:19:33 <dgilmore> cmake is widely used 21:19:35 * jonmasters will ask around about non-autotools platforms 21:19:41 <bconoboy> 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 <bconoboy> jonmasters: you said that 2 weeks ago :-) 21:19:57 <pbrobinson> jonmasters: you said you were going to do that all the way back at FOSDEM when I bought it up 21:20:12 <jonmasters> 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 <jonmasters> when I say "ask" I think what I mean is "raise it as a concern" 21:20:24 <bconoboy> dgilmore: fyi, http://people.fedoraproject.org/~blc/fedora-arm/patchify/configure.pkgs 21:20:32 <pbrobinson> 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 <jonmasters> I suspect we get to figure out how to fix this 21:21:23 <pbrobinson> jonmasters: both debian and suse have build 6K odd packages, what the hell did they do? 21:21:38 <masta> 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 <bconoboy> masta: that's the question 21:22:43 <bconoboy> We can provide patches today for all the autoconf-using packages 21:22:56 <j_dulaney> 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 <j_dulaney> mix 21:23:13 <j_dulaney> At first, individual packagers 21:23:13 <pbrobinson> bconoboy: jonmasters: what did debian and opensuse do? 21:23:21 <nirik> when does this need to be done by? whats the timeframe/pressure? 21:23:22 <ctyler> 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 <jonmasters> pbrobinson: details elsewhere 21:23:26 <j_dulaney> Then have a proven packager go in and finish the job 21:23:32 <pbrobinson> bconoboy: jonmasters: they must have had the same problems so what was done there? 21:23:37 <bconoboy> nirik: It would be nice to have it done before f19 branches. 21:23:58 <j_dulaney> When systemd landed, most individual packagers couldn't be bothered to do the sysv -> systemd transition 21:24:00 <bconoboy> pbrobinson: Afraid I'm not plugged in on those communities. 21:24:09 <j_dulaney> Viking-Ice did much of that himself 21:24:25 <bconoboy> j_dulaney: Yes, leaving it to individual packagers is unlikely to result in prompt result 21:24:28 <jonmasters> ctyler: yea, but it didn't cover the topic of non-autotools 21:24:39 <nirik> so it's planned to build f19 for aarch64? 21:24:47 <dgilmore> masta: no opt out and I will do what needs doing 21:24:54 <pbrobinson> 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 <bconoboy> 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 <j_dulaney> At the least, push to get crit path done by packagers, as well as responsive upstreams 21:25:55 <pbrobinson> hence the reason I was asking jonmasters as well but he hasn't responded 21:26:10 <masta> dgilmore: let me know if you want any help 21:26:18 <jonmasters> 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 <jonmasters> pbrobinson: I specifically haven't responded. We can talk, just not here, sorry 21:26:50 <pbrobinson> 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 <bconoboy> Regardless of what other distros have done, what we do in fedora basically falls into 3 camps: 21:27:03 <jonmasters> sure, we can leverage their experiences 21:27:04 <ctyler> 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 <dgilmore> pbrobinson: +1 21:27:09 <bconoboy> 1. We wait for the package to automatically move to the latest autoconf via upstream 21:27:16 <bconoboy> 2. We have the packager make the change 21:27:20 <pbrobinson> so if we can't talk I don't see what there is to discuss 21:27:23 <bconoboy> 3. We have a proven packager make the change 21:27:41 <dgilmore> bconoboy: 3 is on a proven packager 21:27:44 <jonmasters> 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 <dgilmore> bconoboy: 3 is releng does it 21:27:50 <nirik> 1 will never happy to many packages. ;) Unless there's a reason most upstreams don't switch that very often. 21:27:52 <pbrobinson> 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 <bconoboy> 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 <bconoboy> jonmasters: all we're talking about is patching 21:28:25 * j_dulaney is +1 all three 21:28:45 <pbrobinson> 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 <bconoboy> 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 <bconoboy> dgilmore: Okay, #3 is releng, which in my mind means you :-) 21:30:14 <ctyler> How confident are we that this process is other-platform-safe? If so, what's the concern? 21:30:18 <pbrobinson> 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 <masta> alright how about we knock out the easy autoconf packages first, and we continue searching for packages that need poking? 21:30:36 <pbrobinson> this should have been done weeks/months ago 21:31:06 <bconoboy> yes, it should have been done earlier. do you mean to say it shouldn't be done now because of that? 21:31:08 <pbrobinson> masta: I don't see the point in doing half of them because half a distribution is useless 21:31:08 <jonmasters> pbrobinson: sorry, I thought you were grumbling as to how they got $number of builds done, understand your question now 21:31:19 <masta> pbrobinson: does it make any sense to wait to after branching? is this an all-or-nothing kind of situation? 21:31:44 <dgilmore> masta: its a lot easier before branching 21:32:01 <bconoboy> 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 <pbrobinson> 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 <jonmasters> 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 <pbrobinson> 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 <j_dulaney> Because if crap is fucked up, a lot of that will land on QA (me) 21:33:35 <bconoboy> 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 <bconoboy> dgilmore: same question 21:34:06 <j_dulaney> Peace, y'all 21:34:13 <pbrobinson> 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 <bconoboy> We need a prpopsal before we can go to fesco 21:34:35 <dgilmore> pbrobinson: it will need FESCo approval and a releng mini mass rebuild 21:34:48 <bconoboy> 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 <masta> we should have more data to enable FESCo to make good decisions 21:35:23 <pbrobinson> 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 <jsmith> I agree 21:35:48 <jonmasters> we should prove that it works for a subset of packages 21:36:07 <jonmasters> can issue a number of scratch builds, e.g. 100 on PA 21:36:15 <masta> yes, we should have a risk assesment 21:36:16 <jsmith> 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 <pbrobinson> jonmasters: yes, that would help FESCo make their decision 21:36:21 <nirik> next wed will be 1 day after the branching. ;) but we could indeed try and get a vote in ticket. 21:36:24 <jonmasters> then provide that to FESCo 21:36:46 <bconoboy> Okay, if we're talking to fesco then we're saying this in the context of doing it after branch, right? 21:36:50 <pbrobinson> jonmasters: I suggest your quick 21:36:52 <jonmasters> 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 <pbrobinson> bconoboy: no, that's fesco's decision 21:37:12 <jonmasters> bconoboy: can you and dmarlin_ handle doing the 100 scratch package test today? 21:37:21 <jonmasters> bconoboy: sorry, I mean tomorrow your time? 21:37:42 <bconoboy> jonmasters: Yeah, probably. Is there a list of critical path packages somewhere we can work with? 21:37:44 <pbrobinson> 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 <jonmasters> bconoboy: there is exactly the critical path list 21:38:03 <bconoboy> jonmasters: pointer? 21:38:06 <jonmasters> pbrobinson: do you have the critical path link handy? 21:38:06 <bconoboy> (or anybody, really) 21:38:14 * jonmasters looking 21:38:28 <pbrobinson> jonmasters: No, there's a script in releng repo to generate it for each release 21:38:38 <nirik> https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plain&collctn_list=devel 21:38:52 <jonmasters> thanks nirik that's what I was thinking of 21:38:58 <bconoboy> I'd like to suggest somebody mail the devel list in addition to talking to fesco. 21:39:00 <ctyler> We should also run the BRs for the package set against the unsupported languages list. 21:39:24 <pbrobinson> ctyler: critical path is pretty free of weird languages 21:39:44 <jonmasters> 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 <bconoboy> #link Critical path list is https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plain&collctn_list=devel 21:40:18 <ctyler> pbrobinson: Still, there's weird things like doc tools that need ocaml or haskell that block some pretty key pieces. 21:40:31 <bconoboy> #action bconoboy and dmarlin to do before/after patchify builds on critical path packages to demonstrate safety 21:40:35 <jonmasters> 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 <bconoboy> who wants to mail devel? any objections to doing so? 21:41:02 <jonmasters> #action jonmasters to followup with what Debian and OpenSuSE did for automated patching 21:41:24 <jonmasters> bconoboy: please don't mail devel@ until there are numbers from scratch builds 21:41:37 <pbrobinson> 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 <jonmasters> pbrobinson: +1 21:42:09 <pbrobinson> we don't particularly need a flame war over this at the moment just as ARM is getting good karma 21:42:09 <bconoboy> pbrobinson: An initial "Hey packagers, please update to the latest autoconf for the love of aarch64" 21:42:26 <pbrobinson> bconoboy: I thought that had been done 21:42:32 <bconoboy> has it? 21:42:36 <jonmasters> pbrobinson: indeed 21:42:39 <bconoboy> If so its effect has been quite small :-( 21:42:58 <bconoboy> There are only about 250 packages that recognize aarch64 right now 21:43:22 <pbrobinson> 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 <bconoboy> Okay, who is going to write the fesco ticket? 21:43:45 <bconoboy> pbrobinson: Too much free time I suppose ;-) 21:43:45 <jonmasters> bconoboy: suggest you do 21:43:53 * bconoboy <- bad cop 21:44:07 <bconoboy> #action bconoboy to write fesco ticket 21:44:16 <bconoboy> anybody want to sanity check it before I send it? 21:44:22 <jonmasters> bconoboy: please 21:44:33 <bconoboy> okay- ping me after the meeting if so 21:44:37 <bconoboy> pwhalen: next 21:44:48 <pwhalen> #topic 3) Managing changes in Uboot and boot scripts 21:45:06 <jonmasters> I specifically talked with Grant this evening about this 21:45:15 <jonmasters> I have an alternative idea to the current proposals 21:45:24 <bconoboy> (That's Grant Likely, father of device tree for those wondering) 21:45:34 <jonmasters> It is possible to automatically parse the dtb files and extract the physical memory map for various devices 21:45:38 <pbrobinson> jonmasters: feel free to reply to the list so it hits a wider audience as well 21:45:59 <jonmasters> once that is done, we know the range of RAM and we can infer where U-Boot is loaded 21:46:11 <jonmasters> so we can then determine load addresses 21:46:28 <jonmasters> there is no need in the vast majority of cases to use the "standard" addresses randomly assigned on platforms 21:46:41 <bconoboy> jonmasters: which problem are you solving? 21:46:45 <jonmasters> 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 <jonmasters> bconoboy: standardizing load addresses, determination thereof 21:47:21 <bconoboy> Okay, thanks (We have other parts of the problem to discuss too) 21:47:26 <jonmasters> then the question is what else differs from one platform to another 21:47:26 <pbrobinson> OK, and what about determining which dtb to use? 21:47:44 <jonmasters> and whether we should encode other platform info in a new device tree binding 21:47:53 <jonmasters> then that platform info would be in the dtb itself 21:48:03 <jonmasters> which means we'd see it from within Linux at runtime 21:48:14 <jonmasters> (in a standard location in /proc) 21:48:45 <jonmasters> 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 <jonmasters> anyway, that's enough from me 21:49:06 <bconoboy> Okay, taking a step back, these are the goals I see: 21:49:17 <pbrobinson> jonmasters: sooner rather than later please so you don't lose or forget it 21:49:20 <bconoboy> 1. We want to consolidate all the various images into as small a number as possible. DTB helps with this. 21:49:23 <jonmasters> pbrobinson: ack 21:49:43 <dgilmore> 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 <bconoboy> 2. When upgrading or downgrading kernels we want to ensure that the replacement kernel continues to operate 21:49:51 <dgilmore> jonmasters: at a quick brain dump 21:49:52 <pbrobinson> DTB and unified kernel helps with this 21:50:01 <jonmasters> dgilmore: yea, +1 21:50:10 <bconoboy> 3. We want this to happen without user intervention, like on x86 21:50:32 <jonmasters> dgilmore: kernel/initramfs/dtb addr can be automatically determined, could add specific entries to dtb for overriding 21:50:56 <jonmasters> dgilmore: dtb file name could be in the dtb, along with storage type, filesystem 21:50:59 <jonmasters> dgilmore: in fact, all of it 21:51:05 <pbrobinson> 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 <bconoboy> jonmasters: The dtb idea is good, but it doesn't solve the "which dtb do I load at boot?" question 21:51:09 <dgilmore> jonmasters: not reallt 21:51:10 <ctyler> 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 <jonmasters> 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 <jonmasters> ctyler: right 21:51:50 <bconoboy> 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 <j_dulaney> 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 <bconoboy> 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 <j_dulaney> Rather like loadable modules? 21:52:33 <dgilmore> 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 <j_dulaney> And, if this isn't in the kernel, how difficult would it be to get it there? 21:53:12 <bconoboy> j_dulaney: dtb gets loaded before the kernel is booted, unfortunately 21:53:21 <j_dulaney> Ah 21:53:25 <bconoboy> j_dulaney: at best you have uboot's environment to work with 21:53:34 * j_dulaney waves his ignorance around 21:53:39 <dgilmore> j_dulaney: the dtb tells the kernel what hardware is attached and where 21:53:46 <bconoboy> in many cases uboot itself has a dtb embedded which is really handy 21:53:52 <jonmasters> 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 <dgilmore> jonmasters: thats not really feasable 21:54:42 <dgilmore> jonmasters: anaconda cant use that for instance 21:55:05 <bconoboy> 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 <dgilmore> bconoboy: its a new fucking package 21:55:35 <pbrobinson> 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 <dgilmore> bconoboy: its a new libarary that anaconda can import 21:55:45 <jonmasters> 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 <bconoboy> jonmasters: it's the uboot detection bits that you can't get from the dtb 21:56:14 <dgilmore> we can write a tool that will make us a boot sdcard for different systems 21:56:20 <ctyler> jonmasters: there's more than the load locations involved here 21:56:38 <jonmasters> ctyler: I'm proposing a new binding for devicetree that would have all of the platform info 21:56:58 <bconoboy> jonmasters: won't help with existing platforms 21:57:04 <bconoboy> (it's a good long term strategy of course) 21:57:09 <jonmasters> 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 <dgilmore> jonmasters: and i boot something on my trimslcie 21:57:30 <dgilmore> jonmasters: how does that get loaded and know im on a trimslice 21:57:31 <bconoboy> 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 <jonmasters> 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 <dgilmore> jonmasters: i then put it in my snowball, and it magically works how? 21:58:03 <dgilmore> bconoboy: i started on it today 21:58:20 <bconoboy> dgilmore: can others join in? 21:58:23 <jonmasters> dgilmore: but the database you're asking to write, you're not looking to link that into U-Boot are you? 21:58:29 <dgilmore> bconoboy: yes its on fedora-hosted 21:58:36 <bconoboy> dgilmore: pointer? 21:58:37 <dgilmore> jonmasters: no 21:58:38 <jonmasters> 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 <j_dulaney> dgilmore: Where? 21:58:55 <dgilmore> https://fedorahosted.org/arm-boot-config/ 21:58:59 <bconoboy> jonmasters: No, we want to wire up *all* the dtbs at image ceration time 21:59:04 <bconoboy> dgilmore: awesome 21:59:15 <bconoboy> #link dgilmore has started a new package, https://fedorahosted.org/arm-boot-config/ 21:59:17 <jonmasters> 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 <dgilmore> jonmasters: well image creation time to ensure things are right for the platform. 21:59:45 <dgilmore> jonmasters: but also for use in a tool to setup a installer sdcard 21:59:57 <ctyler> So the only issue here is whether we stuff this into the dtb or create another file (db) to hold it. 22:00:11 <bconoboy> it's not really dtb material is it? 22:00:23 <jonmasters> 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 <bconoboy> pwhalen: I think we're almost there 22:00:37 <ctyler> 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 <dgilmore> jonmasters: no 22:00:46 <jonmasters> bconoboy: the dtb describes the platform, this is platform info, it's plausible to add it there 22:01:06 <pwhalen> we've got a few more topics, should we move this to #fedora-arm, or the mailing list? 22:01:12 <jonmasters> dgilmore: no? no what? 22:01:20 <pbrobinson> mailing list I believe 22:01:24 <dgilmore> pwhalen: well so far my email on it to the list has one reply 22:01:36 <dgilmore> so please people reply to that with your thoughts 22:01:53 <ctyler> 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 <bconoboy> #action jonmasters to reply to the fedora list with his dtb idea 22:02:58 <pwhalen> #topic 4) Arm Koji status update 22:03:34 <pwhalen> nirik, do you have an update? 22:03:48 <nirik> just a quick one... 22:03:53 <pwhalen> perfect 22:04:10 <nirik> things are partially implemented network wise... hopefully done later today. But I've heard that before. 22:04:22 <nirik> it might end up being 2 /24's instead of 1 /23 22:04:39 <bconoboy> #info ARM network almost ready to go for the 3 other chassis 22:04:42 <nirik> I'll be happy to set things up as soon as it exists. 22:04:52 <nirik> probibly we should do firmware update on them too. 22:05:10 <nirik> thats all I had. 22:05:16 <pwhalen> thanks 22:06:11 <pwhalen> #topic 5) ARM Tech Talks - suggestions for future talks, volunteers? 22:06:21 <pwhalen> #info please send any idea 22:06:26 <pwhalen> #undo 22:06:26 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x270d1e90> 22:06:43 <pbrobinson> nirik: we might even have a new kernel soon 22:06:45 <pwhalen> #info please send ideas for future tech talks to the list 22:06:54 <nirik> 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 <nirik> pbrobinson: cool. 22:07:45 <pwhalen> nirik, dont see why not 22:08:01 <pwhalen> #topic 6) Open floor 22:08:05 <jonmasters> on kernel, I'm poking vexpress at the moment, panda I need more time 22:08:22 <jonmasters> there's a backtrace we're getting sometimes in omapdss 22:08:23 <pwhalen> We'll talk a15 next week perhaps? 22:08:29 <jonmasters> pwhalen: sure 22:08:45 * j_dulaney notes to be around for a15 22:08:45 <bconoboy> How are we doing on 3.8? Is it ready to push? 22:08:45 <jonmasters> pwhalen: I've asked dmarlin to start a first cut kernel-lpae 22:08:46 <pbrobinson> pwhalen: or A15 on list, I was going to post a 3.9 kernel plans soon 22:08:51 <nirik> I had a small thing for open floor: 22:09:01 <jonmasters> but pbrobinson and dmarlin can sync on that 22:09:25 <nirik> 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 <j_dulaney> pbrobinson: I got a running 3.9rc1 on x86; it's failed to build on arm so far 22:09:41 <pbrobinson> 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 <bconoboy> nirik: believe the goal from fudcon was to release f19 simultaneous with PA, then push in f20 22:10:03 <ctyler> nirik: at FUDCon we identified an F20 target 22:10:06 <jonmasters> pbrobinson: I am actively debugging the uart (divide by zero) issue - thanks for the regulator changes to vexpress 22:10:13 <pbrobinson> nirik: the plan is at the moment for F20, we need to get a proposal into FESCo soon. 22:10:21 <nirik> bconoboy: cool. ok. 22:10:27 <jonmasters> 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 <nirik> yeah, sooner the better... lead time is good for those discussions. 22:10:41 <nirik> sounds great 22:10:50 <jonmasters> let's ask mlangsdorf to look at the highbank upgrade issue 22:11:00 <pbrobinson> nirik: yea, we really need to start building straight after branch, dgilmore and I are working on it 22:11:10 <jonmasters> 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 <masta> 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 <dgilmore> jonmasters: the way it was done in the past no longer works 22:11:42 <pbrobinson> jonmasters: highbank upgrade issue is purely a kernel.spec I have that in hand, it's easy 22:11:43 <jonmasters> 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 <ctyler> 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 <dgilmore> so we need to test some different things and see what works 22:12:04 <jonmasters> pbrobinson: you've got it? ok then let's just get mark lined up to help you test 22:12:06 <dgilmore> masta: excellent 22:12:11 <pbrobinson> ctyler: what kernel, is this mainline or a branch? 22:12:16 <bconoboy> jonmasters: why mark when it's an rpm dep issue? 22:12:20 <dgilmore> masta: i started the breaking thinsg up process 22:12:22 <pbrobinson> jonmasters: that's the plan 22:12:24 <jonmasters> pbrobinson: it's the 3.4 Google kernel AFAIK 22:12:29 <jonmasters> pbrobinson: thanks 22:12:51 <jonmasters> 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 <ctyler> Exynos5 3.6-3.9 22:13:11 <fossjon> 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 <dgilmore> pbrobinson: we haven't enabled any exynos support yet have we? 22:13:21 <fossjon> and mesa 22:13:22 <pbrobinson> jonmasters: I've heard rumours that the Arndale should boot on 3.9 22:13:29 <jonmasters> pbrobinson: nice 22:13:35 <pwhalen> fossjon, nice 22:13:43 <jonmasters> pbrobinson: I am going to sync with Samsung on Arndale later today as well btw 22:13:54 <pbrobinson> no, I plan on adding an lpae with exynos5 to 3.9 kernel 22:14:09 <pbrobinson> and vexpress a15 and tegra4 and omap5 etc etc 22:14:57 * j_dulaney hasn't had success with building 3.9rc1 on Exynos5 22:15:13 <j_dulaney> Although it looks like a driver issue 22:15:15 <pbrobinson> fossjon: great 22:15:34 * j_dulaney is investigating 22:15:56 * jonmasters hopes in due course that a rep for each board can help debug 22:16:00 <pbrobinson> shall we end meeting and take this back to #fedora-arm? 22:16:11 <jonmasters> I am talking with Linaro about getting their kernel team to also assist with kernel bugs 22:16:12 <pwhalen> pbrobinson, yes 22:16:15 <jonmasters> sure, let's wrap 22:16:19 <pwhalen> #endmeeting