20:00:24 <pwhalen> #startmeeting Fedora ARM weekly status meeting
20:00:24 <zodbot> Meeting started Wed Jun  5 20:00:24 2013 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:24 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore dmarlin masta j_dulaney msalter ahs3 agreene jcapik ddd
20:00:24 <zodbot> Current chairs: agreene ahs3 bconoboy ctyler ddd dgilmore dmarlin j_dulaney jcapik jonmasters masta msalter pbrobinson pwhalen
20:00:30 <pwhalen> .fas pwhalen
20:00:30 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:00:33 <pwhalen> afternoon all
20:00:48 <dmarlin> .fas dmarlin
20:00:49 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:01:02 * masta is here
20:01:21 <ctyler> .fas ctyler
20:01:22 <zodbot> ctyler: ctyler2621 'Christopher Tyler' <chris@mowisp.com> - ctyler 'Chris Tyler' <chris@tylers.info>
20:01:36 * j_dulaney waves
20:01:38 <ctyler> .fas chris@tylers.info
20:01:38 <zodbot> ctyler: ctyler 'Chris Tyler' <chris@tylers.info>
20:02:02 * ctyler is here for the first time in way-too-long, glad not to have a conflict this week
20:02:14 <pwhalen> #topic 0) Status of ACTION items from our previous meeting
20:02:14 <pwhalen> #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-29/fedora-meeting-1.2013-05-29-20.00.html
20:02:20 * jsmith is here
20:02:33 <pwhalen> #info pwhalen to look into LVM console spam on first boot, The initial-setup does not appear to run
20:02:39 <pwhalen> #info BZ#970719
20:03:07 <pwhalen> filed a bz on this, it appears that running initial-setup-text.service causes the endless lvm messages, also why their gone after rebooting
20:03:24 <pwhalen> enabling the service again causes the issue to reappear
20:03:37 <fossjon> :)
20:04:00 * ahs3 sneaks in late
20:04:09 <j_dulaney> .fire ahs3
20:04:09 <zodbot> adamw fires ahs3
20:04:16 <ahs3> :-)
20:04:32 <pwhalen> anything else from last week?
20:05:01 <jsmith> How are we coming on getting 3.10 to boot?
20:05:25 <pwhalen> jsmith, Peter did a scratch build of rc3, worked well
20:05:38 <jsmith> pwhalen: Worked well -- on which boxes?
20:05:40 <pwhalen> rc4 is expected to include those changes and be the same
20:05:48 <masta> pwhalen: nice troubleshooting the LVM thing
20:05:54 <pwhalen> http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing/Fedora_19#kernel-3.10.0-0.rc3.git0.1.fc19_.28scratch_build.29
20:05:56 <jcapik> .fas jcapik
20:05:57 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:06:01 <bconoboy> .fas blc@
20:06:02 <pwhalen> everything !
20:06:02 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:06:14 <pwhalen> that was expected to work at this point
20:06:33 <pwhalen> #topic 1) Problem packages
20:07:02 <pwhalen> Peter isn't joining us today, however :
20:07:03 <pwhalen> pbrobinson> blocking packages we have eclipse for f19 (it should build but there's some weird dep thingy I'm looking at)
20:07:26 <bconoboy> #info Eclipse has a dep issue, pbrobinson investigating
20:08:33 <pwhalen> and systemtap for f20
20:08:41 <bconoboy> #info Systemtap not building in F20
20:08:44 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=969656
20:09:13 <pwhalen> systemtap is blocking quite a bit
20:09:23 <pwhalen> anyone aware of any others?
20:09:44 <jsmith> There's a whole list in bugzilla on the blocker tracker
20:09:45 * j_dulaney doesn't
20:09:50 <j_dulaney> Well
20:10:07 <j_dulaney> Not building is misuse of the blocker bug tracker
20:10:18 <j_dulaney> We need to talk about that at next meeting
20:10:42 <pwhalen> we're talking problem packages here
20:11:06 <j_dulaney> I know, hence saying we need to talk about blockers and the like, but not now
20:11:17 <pwhalen> j_dulaney, coming up
20:11:36 <pwhalen> #topic 2) Kernel Status Update
20:12:25 <j_dulaney> 3.10rc4 in theory should work on Chromebook
20:12:37 <pwhalen> kernel-3.9.4-302.fc19 includes the fix needed for omap graphics
20:12:50 * j_dulaney has had no success in that department, however, it may be because I'm doing something stupid with uboot
20:13:02 <masta> pwhalen: the dss loading order stuff?
20:13:10 <pwhalen> actually looks like 3.9.4-301 includes it as well
20:13:19 <pwhalen> - Add patch to fix DRM/X on omap (panda)
20:13:24 <masta> =)
20:14:09 <pwhalen> and 3.10rc4 is expected to work on all supported platforms
20:14:21 <pwhalen> #link http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=147188
20:14:24 <pwhalen> please test it out
20:14:53 <pwhalen> anything else for kernels?
20:15:22 <pwhalen> #topic 3a) Aarch64 Status Update, problem packages
20:15:44 <bconoboy> We're about 75 done- 10306 packages build out of 13481 total
20:15:49 <bconoboy> 75% that is
20:16:04 <bconoboy> The big blockers now are qt, gcc, and ghc
20:16:15 <pwhalen> #link https://fedoraproject.org/wiki/Architectures/ARM/AArch64/Stage4_Problem_Packages
20:16:32 <bconoboy> Msalter is resolving the qt and gcc builds
20:16:46 <bconoboy> I don't have ghc status- but last I heard it needed porting.
20:16:47 <pwhalen> #info We're about 75% done- 10306 packages built  out of 13481 total
20:16:55 <j_dulaney> I've heard nothing out of upstream ghc
20:17:08 * j_dulaney has cced to all the relevant tickets on their end
20:17:40 <bconoboy> Of the builds that have all dependencies met, over 300 have failed for some reason.  Feel free to chip in and fix those builds.
20:17:50 <msalter> gcc has another day or two unless some problem pops up. It will include gcj.
20:17:53 <j_dulaney> I do not believe that it is a very high priority for them; I guess I could hit their mailing lists to try to light a fire
20:18:15 <oatley> .fas oatley
20:18:16 <zodbot> oatley: oatley 'Andrew Oatley-Willis' <andrew.oatley-willis@senecacollege.ca>
20:19:29 <bconoboy> #info gcc (gcj), qt biggest blockers.  rebuilding now. gcc done soon.
20:19:48 <bconoboy> Also
20:20:06 <bconoboy> If you haven't tried bringing up the model recently, pwhalen has updated the rootfs and docs and such.  It's much easier now.
20:20:19 <bconoboy> I don't even use the console, I just login with ssh.
20:20:41 <bconoboy> #info Updated instructions at https://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart
20:21:06 <bconoboy> The model isn't as fast as hardware, but it's pretty functional at this point.
20:21:20 <bconoboy> vi, wget and other things that were missing a few weeks ago are now all included by default
20:21:35 <bconoboy> So if you had a bad time working with it before, give it another shot
20:21:35 <pwhalen> much more stable as well
20:22:12 <pwhalen> #topic 3b) Aarch64 - are we ready for Koji?
20:22:12 <dgilmore> ill give it a go again, was overly slow and unstable last i tried
20:22:13 <j_dulaney> Nice on the stable
20:22:32 <bconoboy> dgilmore: This one is a question for you, mostly
20:22:37 <pwhalen> this is referring to a separate koji instance
20:22:39 <bconoboy> Right now we're building a snapshot of the f19 rpms
20:22:52 <bconoboy> As f19 wraps up we'll want to switch over to f20
20:23:02 <dgilmore> so we ideally want everything built so we can send all the srpms
20:23:11 <dgilmore> ideally we also have hardware
20:23:12 <bconoboy> ... but maybe instead of using arm-rebuild.sh we should simply work with koji right away?
20:23:47 <j_dulaney> I have heard rumours that there will be h/w at FLOCK
20:24:52 <dgilmore> bconoboy: until we have hardware i think we shouldnt use koji
20:25:15 <bconoboy> dgilmore: It could be a while before we have hardware for this purpose
20:25:36 <oatley> Pretty sure there is a talk at FLOCK which says there will be a live demo on 64-bit ARM
20:25:47 <oatley> hardware
20:25:49 <ctyler> Pros and Cons for and against using koji?
20:25:58 <ctyler> ...before HW arrives?
20:26:13 <bconoboy> Pro: It gets us building f19 and f20 at once
20:26:22 <dgilmore> cons are we will have to patch the timeout on koji
20:26:24 <bconoboy> Current infrastructure doesn't work that way
20:26:41 <bconoboy> any other cons?
20:26:44 <dgilmore> while koji can work with distributed builders its not ideal
20:26:57 <ctyler> dgilmore: Or make it configurable, at last
20:27:11 <ctyler> is it less ideal than using distributed builders in any other scenario?
20:27:19 <dgilmore> if we build in kojiwe really want to make sure the builders are all known and under control management
20:27:34 <bconoboy> 95% of the builds done today are coming from RH lab machines
20:27:47 <bconoboy> check out the IP address log on arm-temp :-)
20:29:03 <bconoboy> It might be easier to get people to contribute fixes with koji scratch builds than asking them to bring up an aarch64 simulator.
20:29:10 <dgilmore> bconoboy: well if we went with koji we would want to setup a proxy where they are
20:29:18 <bconoboy> dgilmore: Sure, no problem
20:29:39 <bconoboy> We did the same thing when builders were at hsv.redhat.com but koji was at seneca.on.ca
20:29:48 <dgilmore> bconoboy: right
20:30:05 <bconoboy> does arm-temp have the horsepower to be a koji hub?
20:30:11 <j_dulaney> Koji itself would run on x86, yes?
20:30:16 <dgilmore> bconoboy: it doesnt have the disk
20:30:19 <bconoboy> j_dulaney: yes
20:30:25 * j_dulaney thought so
20:30:36 <jonmasters> .fas jonmasters
20:30:37 <zodbot> jonmasters: jcm 'Jon Masters' <jonathan@jonmasters.org>
20:30:42 <bconoboy> dgilmore: I can bring up a larger colo server if needed, just need specs
20:30:57 <pwhalen> I like the idea of people being able to use koji, submit builds.. lowers the bar for involvement
20:31:02 <jonmasters> sorry I am so late - another meeting went long
20:31:06 <j_dulaney> +1
20:31:22 <j_dulaney> We ought to have enough built for it, too
20:31:23 <dgilmore> bconoboy: we could probably setup a vm on the box in phx thats hosts arm.koji.fp.o
20:31:24 * jonmasters is +1 as I suggested it :)
20:31:38 <bconoboy> dgilmore: Yeah, that'd be fine too
20:32:09 <dgilmore> bconoboy: the host that has arm-temp on it has about 500G disk
20:32:16 <dgilmore> not going to get us far
20:32:16 <bconoboy> yeah, that just isn't big enough
20:32:36 <dgilmore> it has 2tb in it but most is accounted for
20:32:37 <bconoboy> Okay, let's do this, let's start investigating bringing koji up on aarch64.  It doesn't need to be overnight.
20:32:58 <jcapik> +1
20:33:02 * j_dulaney is +1
20:33:04 <ctyler> +1
20:33:04 <dmarlin> +1
20:33:36 <bconoboy> If we can use the system in phx, so much the better- that's where it will end up eventually
20:33:48 * j_dulaney notes that with the death of his x86_64 box, he is no longer of much help, however
20:33:57 <bconoboy> Then we can add a heavy builder channel and all that good stuff
20:34:07 <dgilmore> bconoboy: i dont like the idea of giving certs to random builders
20:34:32 <bconoboy> dgilmore: The only builders contributing right now are run by msalter, pwhalen, or myself.
20:34:33 <dgilmore> bconoboy: so it will likely limit the builders to those inside Red Hat and exclude outside help
20:34:43 <dgilmore> bconoboy: okay
20:34:49 <dgilmore> just making it clear
20:34:52 <bconoboy> got it
20:35:03 <jcapik> bconoboy: mine should be running too
20:35:03 <bconoboy> #agreed We will begin investigating moving to koji to manage aarch64 builds
20:35:29 <bconoboy> jcapik: You're in the noise (Or possibly using the same outbound IP addr inside RH)
20:35:56 <pwhalen> cool, shall we move on to f19?
20:35:59 <bconoboy> y
20:36:11 <pwhalen> #topic 4a) F19 GA - TC1 testing results, remaining blockers
20:36:11 <pwhalen> #link https://fedoraproject.org/wiki/Category:Fedora_19_ARM_TC1
20:36:29 <j_dulaney> Okay
20:36:46 <j_dulaney> The blocker bug trackers are not the place to file bugs on packages that don't build
20:36:54 <pwhalen> I've been looking at F19 final tc1 using the release validation from primary, for base and desktop unchanged, for install many of the test dont apply
20:37:10 <j_dulaney> They are for tracking bugs that block a release criteria
20:37:14 <pwhalen> #info F19 ARM Blocker
20:37:14 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=901850
20:37:18 <dgilmore> j_dulaney: there is a general ARMTracker bug thats used for that
20:37:31 <j_dulaney> Just making sure
20:37:52 <dgilmore> j_dulaney: afaik we dont use any other tracker buf to track ftbfs on arm
20:38:25 <pwhalen> lxde and xfce are looking pretty good for desktops.
20:38:44 <pwhalen> biggest issue is with intial-setup, text and graphical
20:39:17 <pwhalen> intial-setup-text cause the lvm spam, and intial-setup-graphical doesnt apply the changes
20:39:25 * j_dulaney just worries about the culture shock when ARM goes primary and has to start using the primary blocker process
20:39:45 <dgilmore> j_dulaney: im pushing hard to follow the same processes
20:40:01 <j_dulaney> dgilmore:  It isn't happening
20:40:16 <bconoboy> What issues are remaining vs the "Issues to sovle before F19 ARM GA" email?
20:40:35 <dgilmore> j_dulaney: bit by bit it is
20:41:15 <dgilmore> bconoboy: we have a few things we need to push hard to fix
20:42:09 <pwhalen> bconoboy, initial-setup issues, vexpress boot script, and vfat images
20:42:18 <dgilmore> j_dulaney: help to follow the same procedures is welcome by both me and pwhalen
20:42:47 <bconoboy> dgilmore: what's your list?
20:43:05 <masta> how can we fix the vfat images?
20:43:28 <dgilmore> bconoboy: have anaconda write extlinux.conf files, and run a-b-c
20:43:53 <dgilmore> masta: i'm working on adding vfat kickstarts to git
20:44:31 <dgilmore> we then likely need to patch appliance-tools to make the vfat partition slightly differently
20:44:38 * bconoboy is skeptical of exlinux.conf at this point in the release
20:45:09 <dgilmore> bconoboy: extlinux.conf code exists in anaconda
20:45:28 <dgilmore> just need to use it on arm
20:45:45 <bconoboy> dgilmore: yeah, I'm just wondering what the precedence is when we have both
20:46:09 <dgilmore> bconoboy: highbank will use extlinux.conf
20:46:21 <dgilmore> everything else boot.scr
20:46:23 <pwhalen> we also need a patch to dracut for omap, not sure if thats been submitted yet though
20:46:34 <bconoboy> dgilmore: okay, that means documentation issues at a minimum
20:46:34 <dgilmore> pwhalen: its submitted
20:46:40 <pwhalen> dgilmore, nice, thanks
20:48:04 <bconoboy> dgilmore: Does this give us equivalent abc functionality?
20:49:28 <bconoboy> EG, multiple kernels, sanity for handling which kernel is for highbank and which is not (lpae), optional loading of dtb, rescue mode, etc
20:49:34 <dgilmore> bconoboy: it gives us a menu that will allow us to choose any installed kernel
20:50:32 <bconoboy> dgilmore: Does it pick a default (And does that choice work with grubby --set-default and grubby --get-default)?
20:50:44 <dgilmore> bconoboy: yes
20:51:02 <bconoboy> Cool.  Looking forward to seeing it.  Anyway, carrying on...
20:51:44 <bconoboy> Are we going to have a separate vfat image in GA?
20:51:51 <dgilmore> yes
20:51:58 <bconoboy> can we call it something other than omap?
20:52:04 <dgilmore> im working on the kickstarts today
20:52:17 <dgilmore> it will be just vfat
20:52:43 <bconoboy> good
20:52:52 <bconoboy> Any other serious issues before GA?
20:53:29 <dgilmore> X driver situation needs work
20:53:37 <bconoboy> panda and tegra are solved, right?
20:53:40 <dgilmore> but thats not going to be a blocker
20:53:49 <dgilmore> yeah
20:53:55 <bconoboy> #info f19 ga issues are:
20:53:56 <j_dulaney> How is it not a blocker?
20:54:01 <bconoboy> #info 1. initial setup failing to build
20:54:06 <dgilmore> j_dulaney: well fbdev works
20:54:10 <j_dulaney> x not working hits blocker criteria
20:54:13 <dgilmore> omap works
20:54:18 <bconoboy> #info 2, vfat image creation not correct in appliance-tools
20:54:24 <dgilmore> j_dulaney: X works
20:54:29 <dgilmore> just slowly
20:54:30 <bconoboy> #info 3, a-b-c not running on initial install
20:54:34 <pwhalen> it works, but not using the preferred driver
20:54:45 <bconoboy> #info 4, extlinux.conf not being generated
20:54:58 <bconoboy> #info 5, vexpress X not yet fixed
20:55:06 <pwhalen> initial-setup
20:55:24 <bconoboy> that was #1, I just phrased it wrong
20:55:42 <pwhalen> sorry, missed it :)
20:55:57 <dgilmore> something that may need some work
20:56:00 <bconoboy> #info 6, no vexpress uboot/boot script
20:56:07 <bconoboy> anything else?
20:56:24 <dgilmore> bconoboy: well on primary gnome and KDE are blocking desktops
20:56:54 <dgilmore> KDE on Arm works pretty well. i have filed a bug for plasma wigets not working right
20:57:04 <dgilmore> but gnome doesnt even start
20:57:12 <bconoboy> dgilmore: Strikes me that when arm becomes primary we'll have to change that :-)  Unless we think gnome is light enough for arm.
20:57:34 <ctyler> bconoboy: or ARM is heavy enough for Gnome :-)
20:57:49 <dgilmore> issue is that arm relies on 3d
20:58:21 <bconoboy> arm or gnome?
20:58:24 <ctyler> s/b "gnome relies on 3d" ?
20:58:25 <dgilmore> gnome
20:58:33 <bconoboy> right- no good
20:58:44 <pwhalen> we've always considered xfce our release blocking desktop, something that would be part of the pa proposal?
20:59:07 <fossjon> i think dan loves the mate desktop esp for arm
20:59:19 <fossjon> i wonder if he's here... :)
20:59:21 <fossjon> hehe
21:00:33 <j_dulaney> LOL
21:00:33 <bconoboy> okay, anything else?
21:00:50 <mjg59> There's been a lot of work done on making Gnome work on, say, PPC
21:00:57 <dgilmore> its something thats going to need to be resolved
21:01:01 <mjg59> So I think there's an expectation that all Fedora architectures default to it
21:01:26 * ctyler steps out for another meeting
21:01:28 <dgilmore> mjg59: thats fine, but it just doesnt work.
21:01:50 <mjg59> dgilmore: Well, the code's there
21:01:51 <dgilmore> maybe we need to engage the gnome devs to get it to work
21:02:10 <dgilmore> mjg59: im not going to fix it, i never use it.
21:02:20 <bconoboy> bottom line is ARM doesn't have open source 3d upstream in most cases, so it's not practical to have gnome as the standard desktop.  We should discuss with fesco when it's time to apply for promotion.
21:02:26 <mjg59> I'd be slightly surprised if it's a gnome thing, but I can easily believe that it's a software renderer thing
21:03:10 <dgilmore> mjg59: well llvm is a mess
21:03:25 <bconoboy> pwhalen: let's move on
21:03:41 <pwhalen> shall we consider xfce our release blocking desktop for f19?
21:03:47 <mjg59> dgilmore: Yeah, I'm glad it's not my problem
21:03:55 * j_dulaney doesn't see gnome wokring well as long as arm doesn't have good 3d support
21:03:57 <bconoboy> +1
21:04:15 <j_dulaney> pwhalen:  I thought we already were
21:04:24 <pwhalen> perfect, ok
21:04:32 <pwhalen> #topic 5) Open Floor
21:04:41 <pwhalen> that was it, anything else?
21:04:54 <bconoboy> remember to vote from ARM FLOCK sessions everybody
21:05:16 <pwhalen> #info remember to vote for ARM FLOCK sessions
21:05:17 * j_dulaney has already voted
21:05:24 <pwhalen> #info remember to vote for ARM FLOCK sessions
21:05:30 <bconoboy> #link Vote ARM: https://admin.fedoraproject.org/voting/vote/flock-2013
21:05:49 * j_dulaney just hopes there are none during the hackfest for automated testing; that would take precedence
21:06:52 <pwhalen> #info Please download the latest Fedora 19 ARM TC1 and test!
21:06:57 <bconoboy> link?
21:06:59 <pwhalen> #link http://armpkgs.fedoraproject.org/mash/stage/19-TC1/Images/armhfp/
21:07:02 <bconoboy> woo
21:07:22 <pwhalen> last call
21:07:36 <pwhalen> #endmeeting