21:00:30 <pwhalen> #startmeeting Fedora ARM status meeting
21:00:30 <zodbot> Meeting started Wed Mar  5 21:00:30 2014 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:31 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore dmarlin jdisnard handsome_pirate msalter ahs3 agreene jcapik ddd
21:00:31 <zodbot> Current chairs: agreene ahs3 bconoboy ctyler ddd dgilmore dmarlin handsome_pirate jcapik jdisnard jonmasters msalter pbrobinson pwhalen
21:00:32 <dmarlin> .fas dmarlin
21:00:32 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
21:00:41 <pwhalen> .fas pwhalen
21:00:44 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
21:01:04 <pwhalen> good afternoon everyone, been a while
21:01:47 <bconoboy> happy new year?
21:01:48 <pwhalen> we'll give it a couple of minutes for folks to shuffle in
21:01:53 <dgilmore> hola
21:02:53 * pbrobinson waves
21:02:57 <kylem> moo.
21:02:58 <pwhalen> #topic 1) Kernel Update
21:03:54 <pbrobinson> kylem: baa!
21:04:33 <jcapik> .fas jcapik
21:04:34 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
21:04:40 <pbrobinson> kylem: you taking this first or do you want me to start?
21:04:51 <bconoboy> let's start with pbrobinson
21:05:15 <pbrobinson> so I think we're pretty good in general for ARMv7
21:05:22 <pbrobinson> 3.13 seems pretty decent
21:05:50 <pbrobinson> and for 3.14 I'm looking at what we need for Utilite when I get the time but it's booting on my general daily targets
21:05:56 <dgilmore> 3.14 is working pretty well in my testing
21:06:15 <dgilmore> running it on my cubox-i
21:06:23 <pbrobinson> aarch64 looks OK for 3.14 on Foundation model
21:06:42 <pbrobinson> but it's a moving target
21:06:55 <pbrobinson> kylem: anything to add?
21:07:03 <bconoboy> #info 3.13 appears solid for supported targets
21:07:07 <pbrobinson> anyone else have any queries
21:07:18 <kylem> no, that seems to cover things from my end. unless anyone has a specific issue they want me to look at.
21:07:22 <pwhalen> Ive only had issues with display on 3.13/3.14 on armv7 - trimslice and beaglebone black
21:07:31 <bconoboy> #info 3.14 is being worked on now, utilite is being investigated, other imx6 device support is likely to work as well.
21:07:46 <bconoboy> #info 3.14 looking good on aarch64 foundation model
21:08:49 <bconoboy> pwhalen: are display issues current with the latest versions of 3.13/3.14?
21:08:54 <pwhalen> ok, anything else for the kernel? thought on the display issues?
21:08:59 <pwhalen> bconoboy, yes
21:09:38 <bconoboy> #info Some known issues in 3.13/3.14 with displays on trimslice/bbb, need investigation
21:09:42 <bconoboy> pwhalen: do we have BZs?
21:10:05 <pwhalen> bconoboy, we will, I pester pbrobinson in person. will get some up
21:10:17 <bconoboy> #action pwhalen to file BZs on display issues
21:10:18 <pwhalen> I've heard others report the bbb display working, anyone?
21:10:36 <dgilmore> pwhalen: it worked last i tested
21:10:50 <dgilmore> but ive not tested in a bit
21:10:54 <pbrobinson> so I think we need more testing before bugs
21:11:08 <pwhalen> I have a scratch kernel pbrobinson made in testing.. Ive not had official kernel work
21:11:14 <pbrobinson> I've got a couple of ideas I can poke at and throw scratch builds at pwhalen
21:11:24 <pwhalen> pbrobinson, happy to try em. thanks
21:11:29 <pwhalen> ok, moving on then
21:11:37 <pwhalen> #topic 2) Creating Fedora ARM Remixes
21:12:15 <pwhalen> our officially supported HW list has shrunk.. we're looking to increase the remixes being produced by creating a wiki how-to page
21:12:55 <pbrobinson> so I believe the best way to move these forwards is to have a good documented process for the means of doing them
21:13:07 * masta looks in
21:13:08 <pbrobinson> 1) kernels - what's needed in a kernel for it to work with Fedora
21:13:26 <pwhalen> are there any thoughts on best practice? we discussed a few options, including using qemu to 'install' a custom kernel on an existing image.. or running appliance creator on existing HW
21:13:37 <pbrobinson> it's one of the biggest issues and queries we have how to support a device out of tree
21:13:38 <dgilmore> pwhalen: need to make sure they have generic-release and generic-logos not the fedora-* versions
21:14:08 <pwhalen> dgilmore, I started a page before meeting and do plan on using the official guidelines
21:14:12 <pbrobinson> how can someone take a git tree and plug it into the Fedora kernel build process and get an rpm would be cool
21:14:14 <pwhalen> https://fedoraproject.org/wiki/Architectures/ARM/Creating_Remixes
21:14:49 <pbrobinson> then how do you get that kernel into a standard Fedora image
21:14:57 <pwhalen> pbrobinson, right, what option need to be present, agreed
21:15:18 <masta> yea.. I'd like to compose several remixes... but there is ALOT to improve in my methods...
21:15:22 <dgilmore> pwhalen: would be nice to get working each of the devices we ship dtbs for
21:15:38 <masta> look forward to read the wiki we come up with for the recipies to remix
21:15:46 <bconoboy> dgilmore: that's a lot of devices :-)
21:15:59 <dgilmore> bconoboy: it is
21:16:17 <bconoboy> dgilmore: I'm game though.  If people are willing to put in the time to get devices working I can provide some devices.
21:16:22 <pwhalen> yea.. definitely the most popular devices
21:16:29 <pbrobinson> I would like to see all the .dtb working OOTB so we don't need remixes ;-)
21:16:41 <dgilmore> pbrobinson: right
21:17:14 <dgilmore> im working on changes for u-boot for f21 to make things easier when booting
21:17:22 <pwhalen> lets start with some key devices, and keep expanding out
21:17:35 <pbrobinson> of course
21:17:53 <bconoboy> #info The number of supported devices has decreased over time due to semiconductor decisions (EOL omap3/4 etc)
21:18:16 <pbrobinson> bconoboy: I'm not sure the decreased devices is accurate
21:18:21 <pwhalen> dgilmore, perhaps you could summarize in open floor for our logs
21:18:34 <bconoboy> #info We want to start ramping up the number of supported devices through the use of remixes until F21 comes out
21:18:51 <pbrobinson> bconoboy: omap3 still works, we've added BBones and the imx6 wandboard has effectively replaced the panda*
21:19:19 <pbrobinson> so I think we're steady, but we should be ramping up
21:19:31 <bconoboy> pbrobinson: net more devices are technically supported, but we've lost ground on officially supported as chips are deprecated,  IE, boards thatwe agreed to block releases on
21:19:47 <masta> dgilmore: how so?
21:19:47 * masta likes easy
21:20:04 <dgilmore> pwhalen: will do
21:20:20 <bconoboy> #link Today's how to make a remix documentation is at https://fedoraproject.org/wiki/Architectures/ARM/Creating_Remixes
21:20:22 <pbrobinson> masta: easy like your beagle remix ;-)
21:20:28 * pbrobinson runs away....
21:21:35 <pwhalen> anything else for remixes? or other thoughts for producing them?
21:21:50 <bconoboy> let's get the documentation set
21:22:05 <bconoboy> from there we can use a new board as an example of how to do it
21:22:08 <pbrobinson> documentation documentation .....
21:22:11 <bconoboy> I'll buy board hardware.
21:22:21 <masta> yes - I'd hate to compose wildly bad remixes again, so following a guide is great idea
21:22:24 <dgilmore> pwhalen: ideally they are produced exactly as official images
21:22:44 <pwhalen> dgilmore, the issue we discussed was how someone without hw would do so
21:22:57 <dgilmore> pwhalen: in qemu
21:23:08 <pbrobinson> pwhalen: qemu but we need to document that process
21:23:09 <pwhalen> while possible, somewhat painful.
21:23:23 <pwhalen> so qemu appliance tool, iiuc?
21:23:36 <pbrobinson> pwhalen: painful and documented is better than nothing at all
21:23:50 <pwhalen> if thats all we want to document, no problem.
21:23:51 <pbrobinson> or should I say slow and documented
21:24:06 <bconoboy> There's many ways up the mountain, we can document them all.
21:24:34 <pwhalen> okay, fair enough.. lets not even bring up the tarball :)
21:24:34 <pbrobinson> I would sooner document the safest and easiest way
21:24:41 <dgilmore> pwhalen: a beagleboneblack or wandboard to run it on are not expensive
21:24:42 <bconoboy> But documenting the prefered way that can ultimately transition for remix to official is certainly the more desirable path.
21:24:52 <pbrobinson> NO tarball!
21:25:09 <dgilmore> path to official is ork to get u-boot and kernel support upstream
21:25:11 <masta> to achieve chromebook remix we probably need to update appliance tool to handle gpt disklabels, which we will need anyways for aarch64
21:25:20 <pbrobinson> please lets not discuss cost and move on
21:25:43 <pwhalen> ok
21:25:43 <pbrobinson> cheap for some is unaffordable for others
21:26:04 <dgilmore> pbrobinson: sure, which is why there is always qemu
21:26:08 <pwhalen> #topic 3) ARM representation in Fedora Working Groups
21:26:08 <bconoboy> is anybody besides pwhalen volunteering to help with remix documentation?
21:26:21 <dgilmore> the process requires a working arm system
21:26:22 <pwhalen> bconoboy, masta! :)
21:26:28 <dgilmore> what that is doesnt matter
21:26:37 <bconoboy> okay, moving on..
21:26:46 <pbrobinson> bconoboy: masta is most definitely volunteering
21:27:27 <pbrobinson> for the working groups..... do we have any ARM people on any of the working groups currently
21:27:30 <bconoboy> I think this masta's topic, yes?
21:27:35 <masta> bconoboy: I'm starting to follow the server WG mostly... there was something about switching to xfs recently that kinda spooked me, relating to the remixes thing
21:28:02 <pwhalen> masta, I'll be providing testsuite results
21:28:06 <pwhalen> on XFS
21:28:09 <pbrobinson> I don't see how a filesystem decision affects us at all
21:28:18 <pbrobinson> other than /boot
21:28:36 <bconoboy> right, it's /boot that affects us
21:28:39 <masta> pbrobinson: well the ability to shrink ext4 is nice feature when dealing with arm images
21:28:47 <dgilmore> server wg is considering arm, cloud is keeping it on the radar, workstation is clearly only thinking of x86_64 only
21:29:04 <pbrobinson> masta: we always produce the smallest images and it's generally expansion
21:29:30 <bconoboy> #info Per dgilmore, server wg is considering arm, cloud is keeping it on the radar, workstation is clearly only thinking of x86_64 only
21:29:37 <pbrobinson> dgilmore: I think workstation is looking at ext4 if I follow the disucssion properly?
21:29:44 <bconoboy> #undo
21:29:44 <zodbot> Removing item from minutes: INFO by bconoboy at 21:29:30 : Per dgilmore, server wg is considering arm, cloud is keeping it on the radar, workstation is clearly only thinking of x86_64 only
21:29:56 <bconoboy> #info Per dgilmore, server wg is considering arm, cloud is keeping it on the radar, workstation is only thinking of x86_64
21:30:04 <dgilmore> pbrobinson: btrfs when its ready, ext4 till then
21:30:16 <pbrobinson> dgilmore: yes, that's what I thought
21:30:36 <dgilmore> https://fedoraproject.org/wiki/Cloud_Changelist
21:30:38 <bconoboy> Is the move to xfs the server wg or something larger?
21:31:01 <dgilmore> https://fedoraproject.org/wiki/Workstation/Technical_Specification
21:31:05 <pbrobinson> so from our PoV in the short to medium term, ie F-21 workstation is OK
21:31:09 <masta> I'm planning to participate in future server WGs meetings, as both a liason from BaseWG and for arm related angles
21:31:23 <dgilmore> https://fedoraproject.org/wiki/Server/Technical_Specification
21:31:36 <dgilmore> bconoboy: xfs is server
21:31:41 <bconoboy> #link Cloud WG info https://fedoraproject.org/wiki/Cloud_Changelist
21:31:52 <bconoboy> #link Workstation technical spec: https://fedoraproject.org/wiki/Workstation/Technical_Specification
21:31:55 <dgilmore> bconoboy: boot filesystem on arm has to stay ext for now
21:31:59 <bconoboy> #link Server technical spec: https://fedoraproject.org/wiki/Server/Technical_Specification
21:32:14 <bconoboy> dgilmore: Are you aware of anybody teaching uboot to speak xfs?
21:32:23 <masta> so for workstation... KDE is still our main DE, right?
21:32:38 <dgilmore> bconoboy: nobody is, I checked upstream
21:32:39 <masta> or did we get anywhere with gnome?
21:32:50 <dgilmore> masta: https://fedoraproject.org/wiki/Workstation/Technical_Specification#Hardware_requirements
21:32:52 <bconoboy> #info Server WG is considering xfs for /boot, but uboot doesn't support xfs meaning arm cannot follow this spec.
21:32:59 <dgilmore> they are targeting 64 bit only hardware
21:33:23 <dgilmore> there will be no arm or 32bit x86 deliverable from them
21:33:30 <bconoboy> So, grub speaks xfs?
21:33:35 <mjg59> bconoboy: grub speaks xfs
21:33:43 <bconoboy> tnx mjg59
21:33:54 <pbrobinson> masta: on gnome I'm going to start to poke at the vivante mesa patch set to see if it can make it work
21:34:10 <masta> pbrobinson: that sounds great!
21:34:13 <mjg59> dgilmore: The 64-bit requirement is really x86-centric. If there was any real hope of being able to provide a 32-bit ARM workstation product then I think that could be revisited
21:34:30 <mjg59> But that would rely on working free 3D drivers
21:34:34 <dgilmore> mjg59: I think its doable
21:34:53 <dgilmore> mjg59: vivante i think are almost in a shape we can use
21:35:03 <hrw> sorry, forgot about meeting
21:35:37 <masta> So for the peanut gallery, Vivante support pretty much means iMX6 boards
21:35:55 <dgilmore> mjg59: which is the open source driver that would work on imx6, i.e. wandboard, cubox-i, utilite.
21:36:00 <mjg59> dgilmore: At that point it probably becomes a question of whether there's enough interesting hardware to make it worthwhile
21:36:21 <mjg59> If people want to make it work and it's not going to compromise any other workstation decisions then I don't see it as a fundamental problem
21:36:24 <pbrobinson> mjg59: imx6 is the soc behind most of the interesting HW atm
21:36:27 <bconoboy> #info Workstation spec is 64 bit only and requires 3d drivers: Could be extended to arm32 if 3d drivers become available
21:36:37 <mjg59> pbrobinson: I'm more familiar with imx6 than I want to be
21:36:59 <pbrobinson> mjg59: didn't know you were looking at ARM.... should I send whisky
21:37:09 <mjg59> (Our hardware includes an imx6)
21:37:24 <masta> there is also Lima, they made progress recently
21:37:31 <pbrobinson> mjg59: by "our" do you mean nebula?
21:37:35 <mjg59> pbrobinson: Yeah
21:37:46 <mjg59> No video, though
21:37:47 <dgilmore> masta: right, seems the open drivers are getting there
21:38:28 <pbrobinson> mjg59: interesting, OOB management processor style stuff? sorry happy to take this out of the meeting
21:39:04 <pbrobinson> masta: LIMA has been "making progress" for 2 years now
21:39:32 <dgilmore> I think there will be interesting available arm hardware for the workstartion product, and it ill be able to be made work without comprimising things
21:39:33 <masta> pbrobinson: I sense sarcasm
21:39:54 <dgilmore> even if its only imx6 based
21:40:14 <pbrobinson> masta: nope, I just don't see anything working.... I do with etna_viv in much shorter time
21:40:42 <bconoboy> 2 pwhalens?
21:40:58 <pwhalen_> I dropped, waiting for it to catch up
21:41:03 <dgilmore> bconoboy: he is special
21:41:10 <pbrobinson> bconoboy: WOO! We've cloned him! SUCCESS!
21:41:18 <bconoboy> dgilmore: now I understand how he gets so much done
21:41:24 <bconoboy> pbrobinson: :-)
21:41:27 <pbrobinson> LOL
21:41:29 <pwhalen_> anything else for the WG?
21:41:29 <bconoboy> You're next
21:41:56 <bconoboy> can somebody summarize how this impacts us?
21:41:58 <masta> just try to follow their discussions on the list, and if possible join their meetings =)
21:42:03 <pbrobinson> bconoboy: UK management has been requesting that for months TBF
21:42:12 <bconoboy> IE, do we need to take some action now?
21:42:29 <pbrobinson> OK, so slight diversion... what do we need to agree for working groups?
21:42:34 <pbrobinson> filesystem issues
21:42:37 <pbrobinson> anything else
21:42:45 <dgilmore> bconoboy: probably should talk to the workstation folks about potential for arm support
21:42:49 <pbrobinson> in most cases I think we're fine.
21:42:50 <masta> now that arm is part of the PA group, we should do the needful to ensure we participate the WGs
21:43:11 <bconoboy> Okay, so:
21:43:14 <bconoboy> Server: filesystem issue
21:43:22 <bconoboy> Workstation: 3d driver issue
21:43:25 <bconoboy> Cloud: ??
21:43:27 <pbrobinson> masta: agreed we need to be represented and speak up so we're not forgotten
21:43:53 <dgilmore> cloud is mostly need for widely available hardware supporting virt
21:43:57 <pbrobinson> from the cloud PoV in a lot of cases it crosses over in issues with server in places where it affects us at the moment
21:44:16 <pbrobinson> and it will become more relevant once people look at HW for cloud
21:44:26 <pbrobinson> but I think that will only be an issue for aarch64
21:44:27 <pwhalen> divide and conquer? perhaps have a couple people committed to minimally lurking  on each of the meetings?
21:44:29 <bconoboy> dgilmore: Okay, what hardware would that be? a cubietruck?
21:44:37 <dgilmore> bconoboy: midway
21:44:47 <bconoboy> dgilmore: not widely available, sadly.
21:44:54 <dgilmore> bconoboy: right
21:45:03 <pbrobinson> dgilmore: never to production
21:45:08 <masta> pwhalen: sounds about right
21:45:17 <dgilmore> but server hardware that one would want to deploy a public/private cloud on
21:45:25 <pbrobinson> and virtualisation is as much server as it is cloud IMO
21:45:28 <bconoboy> Cloud: A remix supporting hardware virt
21:46:03 <dgilmore> virt in server case is important too
21:46:09 <bconoboy> okay
21:46:20 <pbrobinson> I think cloud is a discussion that goes hand in hand for aarch64 and other than HW virt images will only ever be a corner case for armv7
21:46:20 <masta> I thought cloud would be a guestOS running inside virt... say an arndale board or cubi-truck
21:46:25 <dgilmore> I just dont see people deploying a cloud on cubitrucks
21:46:26 <bconoboy> Who wants to own what WG?
21:46:32 <dgilmore> you could i just dont see it
21:46:39 * masta will lurk in the server WGs
21:46:47 <bconoboy> dgilmore: makes me wonder if cloud is applicable then
21:46:55 <dgilmore> bconoboy: today not really
21:47:01 <pwhalen> server most interests me, so I will join master, and another
21:47:09 <pwhalen> masta
21:47:17 <bconoboy> Shall we just stick with server and workstation for armv7hl then?
21:47:23 <pbrobinson> What about BaseOS and toolchains
21:47:26 <dgilmore> bconoboy: most likely it will be applicable when aarch64 hardare is widely available
21:47:27 <bconoboy> I'd like to revisit cloud and aarch64 when that's a bit further along
21:47:53 <pbrobinson> I think BaseOS and toolchains are equally important
21:47:54 * dgilmore and masta are base WG members
21:47:58 <masta> =)
21:48:03 <pbrobinson> and toolchains?
21:48:07 <pwhalen> yea, thought so.. any toolchain guys here?
21:48:24 <dgilmore> env and stacks i dont know we have anyone
21:48:25 * pbrobinson votes kylem :-D
21:48:32 * kwizart would be interested in workstation personally (if he would know the address of the group)
21:48:42 <masta> we have jdulany in tool chains I think
21:49:04 <hrw> I would not touch toolchains even with long stick
21:49:05 <masta> if that counts
21:49:18 <pbrobinson> we need someone that is effective
21:49:56 <bconoboy> #action masta to keep an eye on server WG for armv7hl: follow up on HW virt hardware remix and ext2fs issue
21:50:11 <masta> without disparaging the stacks WG, i'm not sure they are doing much that cross pollinates with our arm machinations
21:50:13 <bconoboy> #action dgilmore to keep an eye on workstation WG for armv7hl: follow up on 3d graphics driver
21:50:47 <pbrobinson> masta: explain please what you mean by that
21:51:12 <bconoboy> does somebody have a pointer to this toolchain wg? I'm not clear what hte issue is
21:51:37 <pbrobinson> bconoboy: no issues, just need representation
21:51:47 <masta> pbrobinson: well I'm not sure they have a clear idea of what they are delivering, or perhaps I simply don't know... but there is a big question mark over what they are doing... so until we get a better idea I'd say just ignore them for now.
21:52:05 <bconoboy> I can perhaps cover toolchain wg, just need a pointer
21:52:25 <pbrobinson> masta: I think we should still be represented
21:52:41 <pbrobinson> masta: clear idea or otherwise....
21:53:04 <masta> pbrobinson: I guess you just volunteered ;-)
21:53:37 <pbrobinson> masta: once you man up to do the remix stuff ..... sure!
21:53:38 <pwhalen> alright, we have 7 mins left, shall we move to open floor?
21:53:40 <pbrobinson> why not!
21:53:55 <pbrobinson> pwhalen: sure
21:53:59 <pwhalen> #topic 4) Open Floor
21:54:12 <masta> woohoo... open floor
21:54:15 <dgilmore> I have one issue
21:54:27 <dgilmore> m working on a change for f21
21:54:33 <dgilmore> I'm
21:54:54 <pbrobinson> dgilmore: Change process style change? We are primary remember
21:54:59 <dgilmore> to switch u-boot for everything supported to using extlinux.conf for booting
21:55:09 <dgilmore> pbrobinson: yes
21:55:17 <dgilmore> ive started writing up the change page
21:55:26 <pbrobinson> dgilmore: that needs a change process I would hope, do you have a link to the wiki page for info?
21:55:58 <dgilmore> upstream u-boot suports devicetreedir/fdtdir option in the code that will work out the dtb to load
21:56:20 <dgilmore> we just need to tell anaconda to write out the option in the config
21:56:25 <dgilmore> and grubby to update it
21:56:37 <bconoboy> #info dgilmore is working on swtiching all uboots to use extlinux.conf
21:56:56 <kwizart> dgilmore, which option ?
21:57:09 <dgilmore> http://fedoraproject.org/wiki/Changes/u-boot_syslinux
21:57:20 <dgilmore> kwizart: fdtdir/devicetreedir
21:57:25 <pbrobinson> #info  http://fedoraproject.org/wiki/Changes/u-boot_syslinux
21:57:27 <dgilmore> it can be either
21:57:56 <dgilmore> benefit will be that it should also be easy to pxeboot any box
21:57:57 <kwizart> if it's under a kernel uname -r sub-directory i'm fine, dtbs move too fast
21:58:04 <dgilmore> and to set up a boot.img
21:58:26 <dgilmore> kwizart: thats how things work today
21:58:45 <kwizart> yep, but not on wandboard for f20, so i'm listing
21:59:50 <dgilmore> f20 you also have to specify the exact dtb
21:59:57 <dgilmore> going forward you will not need to
22:00:08 <pwhalen> dgilmore, that'd be great
22:00:16 <pwhalen> look forward to it.
22:00:21 <pwhalen> thanks for the update.
22:00:26 <bconoboy> +1
22:00:30 <pbrobinson> anything else?
22:00:31 <kwizart> dgilmore, should dtb be hardcoded in uboot (as done in tegra ?)
22:00:32 <pwhalen> anything else for open floor?
22:00:33 <dgilmore> I've been working with u-boot upstream and getting traction to simplify and unify things
22:00:53 <pbrobinson> kwizart: can we take the tech details to the ARM list for discussion
22:01:16 <kwizart> pbrobinson, dgilmore can we ?
22:01:20 <dgilmore> I have nothing else, just wanted to give an update on something im working on
22:01:30 <pwhalen> alright, we're in OT.. as a Canadian we do well in OT.. but lets wrap.. last call
22:01:44 * kwizart has two issue to raise on fedora-arm (taken from kernel patches)
22:01:49 <kwizart> issues
22:01:50 <pbrobinson> kwizart: this change has been pretty widely discussed, dgilmore has bought it up a number of times and it's already been on list and to other lists including upstream uboot, nvidia are accepting this as an upstream change for all their devices
22:02:05 <kwizart> 1/ rtc clock on arm is a complete mess
22:02:41 <kwizart> I want pbrobinson to do a public answear about why the rtc cannot be fixed on tegra paz00 , so we can sort that ou
22:02:45 <kwizart> out
22:02:48 <dgilmore> kwizart: i suggest filing systemd bugs
22:03:03 <kwizart> dgilmore, why systemd ?
22:03:03 <pbrobinson> kwizart: why is IRC not public?
22:03:26 <pbrobinson> actually it's probably more dracut than systemd, but I think it covers both off
22:03:48 <pbrobinson> ultimately I don't see it as a solution to compile all RTC into the kernel
22:04:00 <pbrobinson> we currently have 80 of them and that is only going to grow
22:04:00 <kwizart> pbrobinson, right, so please state that
22:04:11 <pbrobinson> kwizart: I have stated it
22:04:13 <dgilmore> kwizart: because building in every rtc driver is not a solution
22:04:21 <kwizart> pbrobinson, on the kernel ml
22:04:27 <dgilmore> kwizart: cubox-i has 2 rtc devices
22:04:30 <pbrobinson> kwizart: it's like building network or storage all into the kernel is not an option
22:04:53 <kwizart> dgilmore, so what is the solution, we are primary fool, we don't knwo the time after the boo
22:04:53 <kwizart> t
22:04:57 <dgilmore> kwizart: /dev/rtc0 is not battery backed /dev/rtc1 is battery backed
22:04:57 <bconoboy> do we have a BZ for this issue?
22:05:13 <pbrobinson> kwizart: fool is not an appropriate response if you want people on side
22:05:36 <kwizart> dgilmore, yep it depends on the device
22:05:39 <dgilmore> kwizart: the solution is to make sure that the rtc device is read when its available
22:06:02 <pbrobinson> kwizart: paz00, even though I have one is not a primary ARM device... it's EOL and a corner case, if we can support it all very well and good but it's not something that is a key blocker
22:06:04 <masta> dgilmore: that is interesting about the cubox-i having two... I wonder why that happened.
22:06:24 <kwizart> dgilmore, right, kernel patches was seen on kernel arm ml on purpose (i cannot find ref)
22:06:33 <dgilmore> masta: they added a second with a battery rather than wiring up a battery to the one on the soc
22:06:40 <hrw> masta: maybe in cpu one and in-one-of-chips-on-board one
22:07:01 <dgilmore> kwizart: kernel is not the right place. i believe that systemd is
22:07:08 <dgilmore> which is why i said file bugs there
22:07:20 <bconoboy> if this isn't going to be solved upstream it's a good candidate for a remix that fixes the issue
22:07:23 <masta> sounds like udev is the right place
22:07:27 <pbrobinson> you can also add a number of random rtc as addons on any ARM devices such as the BBB, do we build all those in as well?
22:07:40 <dgilmore> masta: udev is in systemd
22:07:43 <kwizart> dgilmore, could be, but I want I've already talked to systemd guy about this, nothing to be fixed there for them
22:08:06 <dgilmore> kwizart: have you filed bugs?
22:08:12 <pbrobinson> kwizart: who did you speak with?
22:08:15 <masta> kwizart: if we can write a proper udev rule, I'm sure they would accept the enhancement
22:08:20 <masta> =)
22:09:07 <pbrobinson> kwizart: I spoke with lennart and kay at FOSDEM 12 months ago and they said they were open to options for solutions but they needed a decent problem description and proposed outline of a solution
22:09:31 <kwizart> any way, can be speak about this by raising the issue in public mailing list
22:09:48 <kwizart> I'm not here to make irc meeting a mess,
22:09:57 <kwizart> just want to rise one point
22:09:58 <bconoboy> kwizart: please file a BZ describing the issue
22:10:01 <masta> kwizart: no worries
22:10:04 <pbrobinson> kwizart: you could start by actually stating who you spoke to so we can have a consistent discussion
22:10:15 <pbrobinson> kwizart: and please add it as an ARM blocker bug
22:10:29 <bconoboy> doesn't matter who was talked to in the past, let's get it addressed now using bugzilla
22:10:39 <pbrobinson> perfect
22:10:53 <kwizart> pbrobinson, as I said I want you to answear the patch I've sent on the kernel mailing list, saying what is your current state of mind, not much not less
22:11:29 <kwizart> for both rtc and the fbdev thing  on tegra (which is problem number 2)
22:12:02 <pbrobinson> kwizart: repost it, other than the FBDEV bug that I've responded to I believe I've responded on all cases, you said in the repost you were dropping the RTC discussion so clearly you've changed your mind
22:12:22 <masta> kwizart: we want to wrap-up the meeting soon, but I'll take the bait... what is unhappy with fbdev?
22:12:23 <kwizart> pbrobinson, really as appreciate your work, but I don't undertand your current mood theses days
22:12:36 <pwhalen> perhaps lets bring this to #fedora-arm if you guys want to continue
22:12:47 <bconoboy> yeah, let's wrap
22:12:49 <pwhalen> going to wrap unless there is anything else.
22:13:02 <bconoboy> #action kwizart will file BZes for his rtc and fbdev issues
22:13:04 <kwizart> masta, I would like the discution to keep onlist (kernel ml) that the poing
22:13:07 <kwizart> point
22:13:08 <pbrobinson> kwizart: what mood?
22:13:19 <pwhalen> #endmeeting