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