20:01:04 <pwhalen> #startmeeting Fedora ARM weekly status meeting
20:01:04 <zodbot> Meeting started Wed Apr 17 20:01:04 2013 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:04 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore
20:01:04 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen
20:01:16 <pwhalen> good afternoon all
20:01:21 * masta look in
20:01:24 <pwhalen> .fas pwhalen
20:01:24 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:01:27 * j_dulaney waves
20:01:28 <masta> .fas parasense
20:01:29 <zodbot> masta: parasense 'Jon Disnard' <jdisnard@gmail.com>
20:01:32 <agreene> .fas agreene
20:01:33 <zodbot> agreene: tag4fedora 'Tim Greene' <tagreene@flowserve.com> - agreene 'Andrew Greene' <andrew.greene@senecacollege.ca>
20:01:34 * pbrobinson is here
20:01:38 <oatley> .fas oatley
20:01:38 <zodbot> oatley: oatley 'Andrew Oatley-Willis' <andrew.oatley-willis@senecacollege.ca>
20:01:39 <j_dulaney> .fas jdulaney
20:01:39 <ahs3> .fas ahs3
20:01:41 <zodbot> j_dulaney: jdulaney 'John Dulaney' <j_dulaney@live.com>
20:01:44 <zodbot> ahs3: ahs3 'Al Stone' <ahs3@redhat.com>
20:02:09 <fossjon> .fas .greene
20:02:09 <zodbot> fossjon: agreene 'Andrew Greene' <andrew.greene@senecacollege.ca>
20:02:37 <pwhalen> #topic 0) Status of ACTION items from our previous meeting
20:02:45 <pwhalen> #info -COMPLETE- bconoboy to work out remaining minimal F19 package set requiring aarch64 autotools patching
20:02:58 <pwhalen> #info masta, j_dulaney, oatley to try upstream kernel on a10 devices
20:03:09 <pwhalen> #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-10/fedora-meeting-1.2013-04-10-20.00.html
20:03:15 <bconoboy> .fas blc@
20:03:16 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:03:20 <pwhalen> did you guys have a chance to try the kernel?
20:03:56 <j_dulaney> pwhalen:  No go
20:04:09 <j_dulaney> I built 3.9rc6 on it, but it wouldn't boot
20:04:09 <oatley> pwhalen: Nope, sorry
20:04:36 <bconoboy> pwhalen: is it part of the unified kernel now? or does it have to be rebuilt?
20:04:39 <pbrobinson> j_dulaney: build from source, did you try the defconfig?
20:04:46 <pbrobinson> it is part of the unfied
20:04:52 <pbrobinson> unified
20:04:56 <j_dulaney> pbrobinson:  I did try defconfig
20:05:08 <pwhalen> j_dulaney, was this on the gooseberry?
20:05:11 <masta> I've not had the time to test the A10 kernel, sry
20:05:13 <bconoboy> so what we especially need is for them to test the kernel pbrobinson is building
20:05:18 <j_dulaney> pwhalen:  Indeed
20:05:24 <pbrobinson> likely needs more work, it's on my list but as there's still quite a bit of needed bits missing it's well down the list below mvebu and likely imx6
20:05:48 <jcapik> .fas jcapik
20:05:49 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:06:06 <pwhalen> #info j_dulaney tried 3.9rc6 upstream kernel on a Gooseberry using the defconfig, did not boot
20:06:22 <pwhalen> anything else from last week?
20:07:15 <pwhalen> #topic 1) Problem packages
20:07:39 <pbrobinson> the list is getting there, the last week was terribly busy
20:07:53 <pbrobinson> the main problem package is python3
20:07:59 <pbrobinson> which is being worked upon
20:08:19 <pwhalen> #info python3 current problem package being worked on
20:08:33 <pbrobinson> the latest java build from today is FTBFS but I've already got a bug open for that and it just looks like a patch issue and it's already been assigned
20:09:22 <pwhalen> bz for the logs?
20:09:34 <pbrobinson> awaitng my BZ instance to reload
20:09:44 <pbrobinson> I've already got a lot of fixes that are queued in updates-testing so we're awaiting the tree reopening
20:09:58 <pbrobinson> java-1.7.0-openjdk https://bugzilla.redhat.com/show_bug.cgi?id=953257
20:10:19 <pbrobinson> '#info python3 https://bugzilla.redhat.com/show_bug.cgi?id=951802
20:10:56 <pwhalen> #info java-1.7.0-openjdk FTBFS
20:11:07 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=953257
20:11:45 <pwhalen> anything else?
20:12:00 <pbrobinson> what's the status on tog-pegasus?
20:12:13 <bconoboy> it's ongoing
20:12:15 <pbrobinson> there's not been any movement on it for a number of weeks
20:12:27 <pbrobinson> or at least perceived
20:12:34 <pwhalen> #info python3 https://bugzilla.redhat.com/show_bug.cgi?id=951802
20:12:37 <bconoboy> dmarlin is actively working on it.  it's an atomics issue.
20:12:57 <jsmith> Can we get him to be a bit more vocal?
20:12:59 <j_dulaney> It's always an atomics issue, it seems
20:13:16 <pbrobinson> I thought v7 supported atomics
20:13:31 * j_dulaney thought so, as well
20:13:56 <bconoboy> v7 supports atomics, but tog-pegasus doesn't support armv7 atomics.
20:13:59 <j_dulaney> GCC has pretty darn good atomics support these days
20:14:00 <dmarlin> jsmith: we are debugging a synchronization issue in a testcase that needs atomic operations to work, but so far the patch is not handling it correctly
20:14:35 <j_dulaney> I wish more upstream projects would leverage GCC's atomics support rather than write their own, which isn't arch portable
20:15:24 <pwhalen> on to the next?
20:15:40 <bconoboy> #info tog-pegasus: dmarlin is continuing to work on atomics issues
20:15:58 <bconoboy> pwhalen: y
20:15:59 <pwhalen> #topic 2) Aarch64 patching - status update
20:16:11 <bconoboy> is this config.guess or bootstrap?
20:16:19 <j_dulaney> config.guess
20:16:21 <jcapik> We discussed the aarch64 patching on the last secondaryarch meeting again and my colleagues consider the bug description insufficient (autoreconf needs to be supplied with --install --force switches or their short version -i -v in order to change the config.* files to support aarch64 ... there should be autoreconf BuildRequires mentioned too). They believe it would be good to create a wiki page providing a better description of the
20:16:23 <pbrobinson> patching so the former
20:16:57 <bconoboy> dgilmore: what say you?
20:17:19 <pbrobinson> I agree the description could be improved
20:17:32 <pbrobinson> but it's not completely bad
20:18:14 <jcapik> One more note ... the script generating the package list is going to be enhanced and we expect more bug reports
20:18:59 <jcapik> since some of the packages were skipped even when they don't support aarch64
20:19:46 <dgilmore> jcapik: what secondaryarch meeting?
20:20:30 <pbrobinson> it wasn't a meeting from memory, I though it was just discussed on the channel at the end of last week
20:20:56 <dgilmore> pbrobinson: jcapik explicitly mentioned a secondaryarch meeting and i have no idea what he is talking about
20:20:57 <bconoboy> jcapik: er, who is updating the script?  I think ahs3 has that ball
20:21:01 <ahs3> jcapik: is it autoreconf with --install _and_ --force or is it --install _or_ --force?
20:21:18 <ahs3> bconoboy: yup.  in progress, doing some testing of the changes right now
20:22:13 <pbrobinson> dgilmore: I realise that, I think he's referring to the discussion we had on the channel, it wasn't a meeting though
20:23:41 <pwhalen> maybe we lost him?
20:23:46 <dgilmore> pbrobinson: 20:16 < jcapik> We discussed the aarch64 patching on the last secondaryarch meeting again and my colleagues consider the bug description insufficient
20:23:58 <jcapik> I just tried to explain what meating I'm talking about
20:24:01 <dgilmore> sounds like a meeting outside of the arm meeting
20:24:18 <pbrobinson> ahs3: I believe both, I've found that -vif (which I believe is install, force and verbose) to be the most useful combo that works regularly
20:24:19 <dgilmore> jcapik: where?
20:24:28 <jcapik> dgilmore: private message
20:24:37 <dgilmore> jcapik: i dont have one from you
20:24:53 <bconoboy> Can we start over please?
20:24:59 <ahs3> pbrobinson: that's my understanding, too.  thx
20:25:35 <bconoboy> dgilmore filed bz's, many packages have not yet been updated- who is doing what next?
20:26:00 <pbrobinson> so we've got a couple of things
20:26:07 <pbrobinson> first we need a proposed updated script
20:26:28 <bconoboy> (not it!)
20:26:28 <pbrobinson> who out of jcapik / ahs3 or someone else is handling that
20:26:37 <jcapik> ahs3: it's --install and --force
20:26:40 <ahs3> pbrobinson: i am
20:26:49 <pbrobinson> ahs3: eta?
20:26:55 <jcapik> ahs3: or -i -f ... or -if ... or -i --force or --install -f
20:27:02 <ahs3> jcapik: thx
20:27:18 <jcapik> ahs3: and other combinations
20:27:22 <ahs3> pbrobinson: i hope to start a scan of all the packages this evening
20:27:40 <ahs3> jcapik: right
20:27:48 <pbrobinson> OK so I propose that ahs3 has the action item and we review again next week
20:27:56 <jcapik> ahs3: and even of that there are cases when the files remain unchanged
20:28:26 <pbrobinson> ahs3: can you co-ordinate with dgilmore/me with an updated list so that we can organise to update existing bugs/open new ones
20:28:27 <bconoboy> Is there anything else to be done before ahs3 has his script updated?
20:28:30 <jcapik> ahs3: so the maintainer should explicitly check if the config.* files are changed by the autoreconf -fi
20:28:41 <jcapik> ahs3: I recommend autoreconf -vif
20:29:03 <pbrobinson> once we have an updated list we can work out what message needs to be added to the bugs and process
20:29:06 <bconoboy> #action ahs3 will update the package scanner to better handle false positives and negatives
20:29:09 <pbrobinson> lets get the list first
20:29:40 <bconoboy> #info an updated message with more accurate instructions for recipients will be crafted after the list is regenerated
20:29:46 <bconoboy> what about the existing open BZs?
20:29:55 <bconoboy> Are we proposing to append to them?
20:30:26 <jcapik> bconoboy: we should append a message containing a link to a newly created wiki page
20:30:51 <ahs3> i've started looking thru those BZs to double check their accuracy, too
20:31:14 <bconoboy> any volunteers for crafting a new message with better instructions?
20:31:49 <pbrobinson> bconoboy: I'm happy to work on that with ahs3 and dgilmore
20:31:53 <ahs3> bconoboy: i'd be glad to help
20:32:15 <bconoboy> #action ahs3/pbrobinson/dgilmore will write the updated directions
20:32:23 <bconoboy> okay :-) next?
20:32:33 <pwhalen> #topic 3) F19 Alpha planning
20:32:39 <dgilmore> bconoboy: im not doing any of it
20:32:57 <bconoboy> dgilmore: you can act in an advisory capacity ;-)
20:33:06 <pbrobinson> dgilmore: I just need you for your BZ script and permissions :)
20:33:08 <bconoboy> ("no")
20:34:11 <pwhalen> Do we want to talk kernel status first before Alpha?
20:34:14 <bconoboy> Okay, F19 planning- we need to make an alpha pretty soon
20:34:21 <bconoboy> We have some issues
20:34:29 <bconoboy> live media creator is still broken on f19
20:34:50 <bconoboy> (The anaconda hfstools dependency is fixed though)
20:35:09 <bconoboy> arm-boot-config (gruboot as was) still needs wider testing
20:35:12 <pbrobinson> so what's the issue now?
20:35:16 <pbrobinson> with anaconfa
20:35:19 <pbrobinson> anaconda
20:35:27 <bconoboy> anaconda is fine, lmc simply does not work.
20:35:50 <bconoboy> we can make f19 images with f18's lmc, but not with f19's lmc
20:35:52 <masta> the anaconda problem is in the storaqge setup, but i've not got far with the anaconda folks, they seem to say the logs are right... though I disagree... the problem is in the code that applies the fdisk/disklabel
20:36:04 <j_dulaney> +1
20:36:14 <bconoboy> oh, yeah, anaconda is fine * (But still doesn't grok arm partitioning)
20:36:23 <pbrobinson> so what's the problem with lmc then
20:36:42 <masta> when you create an image, it goes into that part of the creation, then fails.. the image is created in /var/tmp, but if you do fdisk -l /var/tmp/imgname it has no partition tables
20:37:08 <j_dulaney> It gets to Anaconda's partitioning stage and borks
20:37:09 <bconoboy> dmarlin: is what masta talking about the same thing you see or are there two issues?
20:37:15 <masta> no problem with lcm as best I can tell, looks to be in anaconda
20:37:22 <j_dulaney> It essentially goes into an infinite loop
20:37:33 <masta> fyi I just run anaconda directly, manually give it the loop-dev's
20:37:40 <pbrobinson> is there a big difference between f18/f19 code?
20:37:52 <j_dulaney> Even running anaconda manually, it still goes into infinite loop
20:37:58 <masta> yes
20:38:00 <dmarlin> masta: lmc uses anaconda for the insstall
20:38:02 <bconoboy> pbrobinson: huge- recall why f18 was delayed.  the work on both anaconda and lmc are both ongoing
20:38:31 <pbrobinson> How is ARM partitioning so different from x86?
20:39:02 <fossjon> your forced to have a fat32 partition 1?
20:39:05 <masta> not much diff
20:39:09 <dmarlin> I'm not sure livemedia-creator is being used on x86 yet either
20:39:24 <dmarlin> and especially not in --novirt mode
20:39:29 <pbrobinson> fossjon: not on highbank/tegra your not
20:39:39 <masta> pbrobinson: on arm there are some platform specific bits for panda to ensure the /boot filesystem/partition is first thinng so the MLO is first thing.... quirks like that
20:39:46 <pbrobinson> fossjon: and some x86 platforms need a vfat partition too for EFI
20:39:59 <masta> there are not many other partitioning quirks for arm platforms
20:40:12 <j_dulaney> I think anaconda is borking not due to arm/x86 diffs, but due to doing it on filesystem images
20:40:25 <j_dulaney> I get the same bug under x86
20:40:42 <masta> pbrobinson: on x86 the layout of the partitions is not ensured to be this one or that one first thing as one might expect
20:40:55 <pbrobinson> well /boot is first on x86 too and needs to be primary. For main non omap build it doesn't need uboot so does anaconda work in that way?
20:40:56 <j_dulaney> But, in my talks with the Anaconda folks, they seemed to have little interest in fixing it
20:41:12 <bconoboy> dmarlin: is what masta talking about the same thing you see or are there two issues?
20:41:25 <masta> pbrobinson: look for platform.py in anaconda to see what I'm talking about
20:41:44 <dmarlin> not entirely sure, but I think j_dulaney has it right... not just an arm issue
20:41:46 <pbrobinson> I have no urge to look at anaconda python code, I have enough to deal with
20:42:03 <masta> bconoboy: I agree, I don't think this is just an arm issue either
20:42:12 <pbrobinson> my question is does it work with 3 partitons of /boot / and swap?
20:42:13 <masta> pbrobinson: :)
20:42:33 <dmarlin> I think it's due to the fact we are using lmc (which is not being used much) and using --novirt
20:42:43 <j_dulaney> pbrobinson:  It goes to create a disklabel and that's where it stops
20:42:44 <pbrobinson> because for the multiplatform default that's all we need
20:42:51 <masta> bconoboy: which implies it's a possible issue of how LMC invokes anaconda
20:43:21 * masta is not sure, needs more time to poke... or time in general
20:43:25 <j_dulaney> pbrobinson:  It doesn't even get to the partition creation step
20:43:41 * j_dulaney will poke some more tonight
20:43:52 <masta> j_dulaney: let's coordinate
20:43:59 <j_dulaney> masta:  Roger
20:44:10 <pbrobinson> I don't see why it should be any different for our default target than x86
20:44:23 <pbrobinson> what's the kickstart that's being used?
20:44:26 <dmarlin> I was doing some tracing (during this meeting) and it seems to be asking a question (which is not allowed in command line mode), but not erroring out... just waiting
20:44:59 <pbrobinson> dmarlin: what's the question? All questions should be answerable in a kickstart?
20:44:59 <j_dulaney> pbrobinson:  I've hit the bug with several kickstarts, including the x86 kickstart used to install F19 on my x86 laptop
20:45:14 <dmarlin> pbrobinson: not from lmc (command line mode)
20:45:17 <pbrobinson> j_dulaney: are there bugs open for those?
20:45:30 <j_dulaney> pbrobinson:  I don't know; I haven't opened any
20:45:31 <pbrobinson> dmarlin: does lmc not use a kickstart?
20:45:37 <dmarlin> pbrobinson:  it does
20:45:38 <j_dulaney> It does
20:45:55 <j_dulaney> masta dmarlin:  Have y'all opened any bugs?
20:45:59 <pbrobinson> dmarlin: so you should be able to specify it there without cmd line
20:46:06 <j_dulaney> If not, I'll open up one right after the meeting
20:46:06 <dmarlin> j_dulaney: I have two
20:46:11 <j_dulaney> Okay
20:46:37 <j_dulaney> dmarlin:  Numbers?
20:46:38 <pbrobinson> j_dulaney: please file bugs for those issues, there should be no regressions in kickstarts and i know of a couple of people that are making sure there's no regressions there
20:46:59 <pbrobinson> dmarlin: what are they?
20:47:17 <dmarlin> pbrobinson: looking... please be patient
20:47:25 <pbrobinson> OK
20:47:51 <masta> j_dulaney: no BZ yet, i'd like to have a solid problem-statement first
20:48:09 <dmarlin> pbrobinson: one is 920764
20:48:47 <dmarlin> pbrobinson: another - 895258
20:48:54 <dmarlin> pbrobinson: those started in f18
20:48:58 <bconoboy> #info F19 alpha image generation is being held up by problems with live media creator and/or anaconda
20:49:15 <bconoboy> #link livemedia-creator fails to make an ISO image using --novirt: https://bugzilla.redhat.com/show_bug.cgi?id=920764
20:49:53 <bconoboy> #link livemedia-creator appears to hang when using --novirt --image-only: https://bugzilla.redhat.com/show_bug.cgi?id=895258
20:50:22 * j_dulaney just cced
20:50:24 <pwhalen> anything else we should discuss for f19 alpha? (kernel is next)
20:50:28 <pbrobinson> dmarlin: thanks
20:50:31 <dmarlin> np
20:50:49 <pbrobinson> can everyone make sure that any arm BZs are linked against the tracker bug please?
20:50:54 <bconoboy> What're we tentatively supporting in f19 alpha?
20:51:12 <bconoboy> highbank, tegra, omap, vexpress, anything else?
20:51:51 <pbrobinson> at the moment that will do, I've started looking closer at mvebu
20:52:06 <pbrobinson> but I think that'll be better for beta
20:52:23 <j_dulaney> pbrobinson:  Which tracker, F19Alphablocker?
20:52:24 <bconoboy> mvebu will only work with appended dtb
20:52:28 <bconoboy> fyi
20:52:33 <pbrobinson> ARMTracker
20:52:37 <j_dulaney> Ah
20:52:40 <masta> bconoboy: =(
20:52:40 * j_dulaney will do so
20:52:51 <bconoboy> #info Current F19 alpha target platform list: highbank, tegra, omap, vexpress
20:52:56 <pbrobinson> that's due to shit support of uboot from Marvell
20:52:58 <bconoboy> masta: no uboot support for dtbs yet
20:53:17 <masta> mvebu is that really true of all Armada boards, or just boards with a bad u-boot?
20:53:45 <bconoboy> masta: I have seen just about every mvebu-using-board in existence and none of them support dtbs.
20:54:17 * masta has a mirabox armada-370 kit shipping to him right now, to test mvebu
20:54:43 <masta> bconoboy: ok well that answers the question, thx ;)
20:54:55 <j_dulaney> lmv bugs now blocking armtracker
20:55:00 <pbrobinson> well what else do we have to cover for alpha?
20:55:02 <j_dulaney> s/lmv/lmc
20:55:16 <bconoboy> it would be good if more people who test the arm boot loader generator
20:55:21 <bconoboy> currently pwhalen is rocking with it
20:55:25 <bconoboy> http://people.fedoraproject.org/~blc/fedora-arm/arm-boot-config/
20:55:35 <pwhalen> great tool if your testing kernels
20:55:45 <pwhalen> and all around of course :)
20:55:53 <bconoboy> #link Enjoy uboot kernel menus, recover from bad kernels with ease, try http://people.fedoraproject.org/~blc/fedora-arm/arm-boot-config/
20:56:09 * j_dulaney did not know of that
20:56:21 <bconoboy> currently well tested on tegra and highbank
20:56:37 <bconoboy> might work on omap and armada xp
20:56:40 <dmarlin> bconoboy: which u-boot required on trimslice?
20:56:48 <bconoboy> dmarlin: 2012 uboot
20:57:20 <pwhalen> it was tested on the Pandaboard too, however the Pandaboard doesnt boot with a dtb that I know of
20:57:40 <bconoboy> Also, if we're going to support a10 would somebody send me the output of their uboot's 'printenv' and their working boot.scr?
20:58:30 <pwhalen> j_dulaney, do you have a serial connection on your gooseberry?
20:58:33 * masta will do printenv on his googeberry/hackberry thing
20:59:19 <pwhalen> masta, same question
20:59:21 <bconoboy> pwhalen: pandaboard doesn't support dtb?
20:59:22 <j_dulaney> pwhalen:  I do
20:59:43 <pwhalen> soldered it on?
20:59:48 <j_dulaney> pwhalen:  Aye
20:59:56 <masta> pwhalen: I will make a cable if I have to
20:59:57 <pwhalen> bconoboy, it doesnt boot when you select the dtb
20:59:58 * j_dulaney has mad soldering skillz from building models
21:00:01 <bconoboy> #info Currently supports tegra, highbank, omap: Contact bconoboy to add support for your device
21:00:09 <pwhalen> only boots without one
21:00:21 <bconoboy> pwhalen: This 3.9?
21:00:26 <pbrobinson> right can we get back on topic please
21:00:27 <pwhalen> been considering soldering one onto the board too
21:00:31 <pwhalen> sorry
21:00:34 <bconoboy> sorry, yeah
21:00:36 <pwhalen> bconoboy, it is
21:00:38 <pbrobinson> what's outstanding on the alpha topic?
21:01:00 <bconoboy> other stuff we won't know about until we have images to tet
21:01:04 <bconoboy> er, test
21:01:08 <pbrobinson> we're on the hour
21:01:11 <pwhalen> revisit next week?
21:01:13 <bconoboy> y
21:01:14 <pwhalen> okay
21:01:16 <pbrobinson> so what else needs to be covered
21:01:20 <pwhalen> #topic 4) 3.9 Kernel Update
21:01:49 <pbrobinson> so as of today we have a booting 3.9 kernel on tegra/vexpress/highbank and omap!
21:01:59 <pbrobinson> none are particularly stable
21:02:04 <bconoboy> with caveats :-)
21:02:16 <pwhalen> #info kernel-3.9.0-0.rc7.git0.2.fc19 booting on tegra/vexpress/highbank and omap
21:02:20 <pbrobinson> but they're working with a multiplatform kernel which is a good start!
21:02:38 <pbrobinson> so next up is stabilisation
21:02:46 <pbrobinson> and getting mvebu booting
21:02:51 <pwhalen> #link https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing/Fedora_19#kernel-3.9.0-0.rc7.git0.2.fc19_.28scratch_build.29
21:03:16 <pwhalen> #link http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1716496
21:03:16 * ahs3 ^5s pbrobinson
21:03:28 <pwhalen> its a scratch build, so harder to find
21:03:43 <pbrobinson> there's a proper build on its way
21:03:43 * j_dulaney notes also that 3.9 boots to text console on Exynos5
21:03:53 <j_dulaney> As of RC5
21:04:01 <pwhalen> j_dulaney, our lpae?
21:04:02 <pbrobinson> j_dulaney: as in the Fedora kernel does?
21:04:15 <j_dulaney> Custom built one, but all stock
21:04:26 * j_dulaney hasn't tried the latest fedora lpae
21:04:34 <j_dulaney> as in, all mainline
21:04:51 * j_dulaney will try the latest lpae build
21:05:02 <pbrobinson> j_dulaney: not much use to general use, sorry, I would love a diff of what's needed, or the .config to get that booting kernel
21:05:58 <masta> j_dulaney: send me the .config too
21:06:24 <masta> j_dulaney: I'll help to diff with the lpae... make it easier on Peter
21:06:30 <pwhalen> anything else for the kernel?
21:06:54 <pbrobinson> masta: grab the config generated in the lpae kernel and use that as a base
21:07:05 <pbrobinson> pwhalen: nope, I don't think so
21:07:14 <pwhalen> #topic 5) Open Floor
21:07:16 <j_dulaney> masta:  I'll email it your way post-meeting
21:07:26 <pbrobinson> if anyone had any idea as to the crashes in both tegra and highbank I would love some feedback on that
21:07:38 <pwhalen> #info Trimslice now working with firmware v2012.04-1.02 (1 GB RAM now available)
21:07:39 <pwhalen> #link http://www.trimslice.com/wiki/index.php/Trim-Slice_Firmware_Updater#U-Boot_environment_variable
21:08:00 <bconoboy> pwhalen: stage4 bootstrap wiki pointer?
21:08:38 <pwhalen> #info initial stage4 bootstrap Quickstart page
21:08:48 <pwhalen> #link https://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart
21:09:06 <pwhalen> #info this includes kernels for use with a disk image or nfs root
21:09:31 <pwhalen> please have a look, try it out and let me know if I missed anything.. the last part will be to add the bootstrap instructions
21:09:42 <bconoboy> We'll have a final stage4 rootfs really soon- like later today or tomorrow
21:10:06 <pwhalen> as it is now, mock will work but will require an edit of the config to disable the stage4 repo until its available
21:10:16 * j_dulaney notes that the filesystem from last week didn't boot without tweaking
21:10:17 <bconoboy> Once it's ready we can fill in the 'Getting Started with the Aarch64 Bootstrap' section
21:10:42 <pwhalen> #info recommend usage with an NFS root
21:10:54 <bconoboy> j_dulaney: Would you send any feedback to the mailing list?  That way we can make sure people don't have to rediscover fixes
21:11:09 <pwhalen> j_dulaney, with a disk image?
21:11:22 <j_dulaney> It wasn't a disk image, just filesystem
21:11:48 <j_dulaney> bconoboy:  I'll try the new disk image and see if I still have issues
21:11:55 <pwhalen> worked okay as is for me with an nfs root, or the disk image
21:11:59 <mlangsdorf> pbrobinson: highbank dma related crashes may be related to still another bug in that subsystem (don't dereference NULL pointers!)
21:12:00 <pwhalen> thanks
21:12:25 <mlangsdorf> probinson: but i haven't had a chance to look at Paul's latest stuff and won't before Friday.
21:12:28 <j_dulaney> bconoboy:  I had to manually populate /dev
21:12:35 <pwhalen> mlangsdorf, thanks
21:13:00 <j_dulaney> No biggy, I have a script to do that, but still, just note that it happened
21:13:13 <bconoboy> I'd have thought udev would populate /dev
21:13:35 <j_dulaney> bconoboy:  Not the first time I've had udev not doing it's job in aarch64
21:13:44 <j_dulaney> Hence writing the script
21:14:26 <pwhalen> anything else for the meeting, or shall we move it to #fedora-arm?
21:14:29 <j_dulaney> I'll poke some and if needed, file a bug report
21:15:30 <pwhalen> #endmeeting