15:00:19 <pwhalen> #startmeeting Fedora ARM & AArch64 Status Meeting
15:00:19 <zodbot> Meeting started Tue Dec 16 15:00:19 2014 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:20 <pwhalen> #chair pwhalen jonmasters bconoboy pbrobinson dgilmore dmarlin hrw jsmith kyle ahs3
15:00:20 <zodbot> Current chairs: ahs3 bconoboy dgilmore dmarlin hrw jonmasters jsmith kyle pbrobinson pwhalen
15:00:25 <pwhalen> .fas pwhalen
15:00:26 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
15:00:28 <pwhalen> good morning all
15:00:30 <dgilmore> hi
15:00:40 <ahs3> .fas ahs3
15:00:41 <zodbot> ahs3: ahs3 'Al Stone' <ahs3@redhat.com>
15:00:59 <rwmjones> bconoboy: hello .. wanted to ask about Rawhide images, in general, and in beaker
15:01:15 * pbrobinson is here
15:01:24 <dgilmore> rwmjones: we currently do not make them
15:01:29 <dgilmore> we do need to do so
15:01:38 <dgilmore> but its going to need quite a bit of work
15:02:08 <yselkowitz> .fas yselkowitz
15:02:10 <zodbot> yselkowitz: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
15:02:18 <bconoboy> .fas blc@
15:02:20 <zodbot> bconoboy: blc '' <blc@redhat.com>
15:02:31 <kylem> .fas kylem
15:02:32 <zodbot> kylem: kymully 'Kyle Mullan' <kylemullan@gmail.com> - kylemanna 'Kyle Manna' <kyle@kylemanna.com> - kyle 'Kyle McMartin' <kmcmartin@redhat.com>
15:02:39 <kylem> er, heh, whichever one i am.
15:02:47 <pbrobinson> LOL
15:02:51 <pwhalen> thanks for coming folks, lets get started
15:03:12 <pwhalen> #topic 1) ==== Fedora 21 (aarch64) ====
15:03:12 <pwhalen> #info F21 RC7 Testing Summary
15:03:12 <pwhalen> #link https://fedoraproject.org/wiki/Architectures/AArch64/QA/21_RC7_Testing
15:03:50 <pwhalen> #topic 1a) == Open Bugs ==
15:04:01 <pwhalen> #info Installer unable to add bootloader EFI entry on AArch64
15:04:01 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi? id=1151571
15:04:14 <pbrobinson> so what's remaining, what do we need to block the release for and what can be fixed post release?
15:04:35 <pjones> #link https://bugzilla.redhat.com/show_bug.cgi?id=1151571
15:05:06 <pwhalen> I hit this one again, same circumstances, pxe is the first menu entry. believe this is a tiancocore bug and we just need to document it in known issues
15:06:27 <pbrobinson> I thought it was already agreed that it was a firmware bug and would be documented as a common bug?
15:06:48 <pwhalen> ok, my mistake
15:07:19 <pwhalen> #agreed BZ#1151571 to be included in known issues
15:07:34 <pbrobinson> pwhalen: I might have missed something, maybe someone else can confirm
15:07:35 <pwhalen> #info Unable to enter passphrase for encrypted rootfs when no 'console=' is included on aarch64
15:07:35 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1172740
15:08:01 <pwhalen> pbrobinson, no I think youre right, recycling notes from last weeks meeting
15:08:39 <pwhalen> this is one we had hoped would be fixed in RC7, however it looks like there is more to it, kyle may be able to give some more details
15:08:47 <pwhalen> kylem, that is
15:08:52 <kylem> sec
15:10:52 <kylem> seems to be some kind of interaction between systemd-tty-ask-password-service and the console drivers.
15:11:29 <pwhalen> it works when the console is specified in the kernel args
15:11:46 <bconoboy> document or fix?
15:13:00 <pwhalen> I'm okay with documenting it. I dont know how many will use encrypted, and adding the console is easy enough.. other thoughts?
15:13:17 <bconoboy> I'm for document as well
15:13:19 <kylem> i'm trying to piece together which bit is which, the annoying thing is it's hard to 'reproduce' on x86 or something because of the implications
15:13:36 <bconoboy> unless some other showstopper comes up in testing
15:13:54 <kylem> of having vga
15:14:53 <pwhalen> right. ok we have two folks saying document, need a few more
15:15:05 <pwhalen> dgilmore, pbrobinson ?
15:15:11 <pbrobinson> I think we can document the work around as it works with the documentation
15:15:25 <pbrobinson> and fix it in a later update
15:15:47 <kylem> i'm fine with documenting for f21, but i'll try fixing it as well.
15:16:00 <pwhalen> awesome thanks kylem
15:16:33 <pbrobinson> I believe moving forward it needs to be fixed, but as we have a workaround that's easy to document I don't believe it's a release blocker
15:16:34 <pwhalen> not sure if anyone is using encryption yet
15:16:41 <kylem> i'm trying to (and failing) to find the piece which is parsing for it, but i'm sure it can be fixed by looking for the active console in /proc/consoles.
15:16:47 <pwhalen> agreed.
15:18:24 <pwhalen> #agreed while unfortunate, document bz#1172740 in known issues, fix after release
15:18:54 <kylem> heh.
15:18:57 <kylem> uh.
15:19:13 <kylem> does it work if you specify all possible consoles for both seattle and mustang?
15:19:53 <dgilmore> i would say that we should do as is done on x86
15:20:08 <pbrobinson> kylem: wasn't the explicit console= setting dropped to allow auto config to deal with DT -> ACPI transition?
15:20:12 <pwhalen> havent tried that, only did the same encrypted install adding the console to the kernel args, and it worked
15:20:39 <dgilmore> though you only get a serial console on x86 by adding console=
15:20:48 <bconoboy> pbrobinson: yes, it's the only sane way to be forward compatible
15:20:49 <dgilmore> so expecting it to be added is okay
15:20:54 <pwhalen> then it would match :)
15:21:12 <pbrobinson> dgilmore: it's not exactly the same as x86 due to x86 just defaulting to ttyS0 for serial console
15:21:51 <dgilmore> pbrobinson: it doesnt default to ttyS0 it defaults to no serial console and only a console on tty0
15:22:15 <dgilmore> if you want a serial console you need to explicity ask for it
15:22:26 <kylem> pwhalen, maybe we should just write out the default args to list them all explicitly for F21, and then we can fix it later.
15:22:29 <dgilmore> so requiring that on aarch64 is okay
15:22:30 <pbrobinson> dgilmore: I blame jonmasters because of the ridiculous non standard ttyBLAHBLAH0 naming required for the arm server standard thing instead of just using ttyS0 like the rest of the server world
15:22:44 <dgilmore> pbrobinson: yeah thats pretty silly
15:23:03 <pbrobinson> dgilmore: in the case of a serial console it defaults to ttyS0
15:23:20 <dgilmore> pbrobinson: sure.
15:23:27 <kylem> eh, ttyS is for 8250 serial consoles and things which look like them. tty{whatever else} is not unique to this situation.
15:23:31 <bconoboy> Seattle with device tree uses ttyAMA0, there is no sane default, that's why we're having the firmware and kernel sort things out.
15:23:46 <kylem> (and a stupid s390 driver because they're silly.)
15:24:02 <pbrobinson> bconoboy: there's no sane default on arm*
15:24:06 * rwmjones wishes ttyS0 would always be "the first serial console" (on all arches)
15:24:25 <bconoboy> pwhalen: I think we can move on
15:24:30 <kylem> "first" is meaningless. anyway, let's move on.
15:25:20 <dgilmore> we can move on
15:25:21 <pwhalen> some of these may not be relevant
15:25:32 <pwhalen> #info No KVM virtualization on APM Mustang and other boards (3.17.4/f21 and 3.18-rc/f22)
15:25:32 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1165290
15:25:49 <pwhalen> thats fixed
15:25:57 <dgilmore> okay :)
15:26:01 <pbrobinson> didn't kylem fix this with the latest kernel in rc7?
15:26:09 * kylem doesn't remember.
15:26:12 <rwmjones> this is fixed in the latest kernel for sure
15:26:13 <pwhalen> #info fixed in RC7
15:26:30 <rwmjones> because I dropped the patch I was carrying for it, and virt works for me
15:26:33 <kylem> 2298 - arm64-vgic-error-to-info.patch: change an error to a warning so that
15:26:37 <kylem> 2299   kvm will work.
15:26:46 <kylem> i think that's the 'kludge' we were carrying in That Other Thing, for it.
15:26:57 <kylem> so yeah, probably "fixed" for now.
15:27:04 <pwhalen> #info aarch64: anaconda in VM dies with "SystemError: Could not determine system architecture." because blivet assumes aarch64 always has EFI
15:27:04 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1128341
15:27:33 <rwmjones> this is closed
15:27:40 <pwhalen> just noticed.
15:27:47 <pwhalen> ok, thats it then.
15:28:03 <dgilmore> vms need to use uefi
15:28:13 <pbrobinson> well it's closed, but it's not fixed, but it's not a release blocker either IMO
15:28:17 <pjones> ... which they can't currently do because of license restrictions.
15:28:21 <bconoboy> agree with pbrobinson
15:28:50 <bconoboy> It's an enhancement we ought to do during f22 development, to ensure the widest possible coverage of aarch64 devices.
15:29:08 <pbrobinson> it does need to be fixed for more reasons than just VMs, we need to be able to support uboot moving forward, but I don't believe it's worth blocking for it
15:29:33 <pbrobinson> if it's closed can someone re-open it so it's properly tracked?
15:29:39 <dgilmore> supporting u-boot in anaconda will be quite a bit of work
15:29:40 <bconoboy> dlehman has provided me some pointers on updating python-blivet to support aarch64+uboot.  If anybody wants to take a crack at it I will forward.
15:29:47 <bconoboy> It looks fairly straight-forward.
15:29:58 <dgilmore> but i can go with it not being release blocker
15:29:58 <pbrobinson> dgilmore: not according to others
15:30:37 <pwhalen> can we not chainload efi? forget uboot altogether?
15:30:54 <kylem> pwhalen, we can't (currently) redistribute uefi.
15:31:01 <dgilmore> pbrobinson: its not a few lines of code. It's likely a fair bit more work. to get something testable is likely not too hard. its just going to need a lot of testing to cover all the corner cases
15:31:31 <pbrobinson> dgilmore: of course.... but then that's everything to do with anaconda ;-)
15:31:38 <bconoboy> This BZ actually encompasses 3 different issues which makes it somewhat confusing.
15:31:39 <dgilmore> yep
15:31:55 <dgilmore> bconoboy: right, we should likely file new bugs for each of them
15:31:57 <bconoboy> 1: You need an UEFI environment for virt guests, but can't get one due to vfat licensing restrictions
15:32:17 <bconoboy> 2: python-blivet assumes all aarch64 systems are UEFI which is not true
15:32:47 <bconoboy> 3: We've never tested Fedora installs of aarch64 with uboot, so there may be additional issues beyond python-blivet
15:33:24 <pwhalen> so two for now, with a possible third
15:33:43 <yselkowitz> wasn't kylem working on a new vfat driver?
15:34:28 <kylem> yes.
15:34:30 <bconoboy> dgilmore: are you going to produce a uboot binary for aarch64 hosts?
15:34:50 <dgilmore> bconoboy: we build a u-boot binary for aarch64
15:34:52 <pwhalen> #agreed BZ#1128341 to be split up into two separate bugs. 1) You need an UEFI environment for virt guests, but can't get one due to vfat licensing restrictions 2)  python-blivet assumes all aarch64 systems are UEFI which is not true
15:35:02 <dgilmore> bconoboy: no idea if it works
15:35:05 <bconoboy> dgilmore: does it work? :-)  Not for installs, I mean just does it come up?
15:35:08 <bconoboy> Ahh, hmm
15:35:18 <bconoboy> Okay, let's take it offline
15:35:47 <dgilmore> we have /usr/share/uboot/vexpress_aemv8a/u-boot.bin in uboot-images-armv8
15:36:09 <dgilmore> I have not tested it at all
15:37:11 <pwhalen> ok, anything else for open bugs? more discussion on this one?
15:37:38 <bconoboy> Sounds like we don't have any blockers identified in rc7 yet.
15:38:12 <pwhalen> we do not
15:38:25 <pbrobinson> bconoboy: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=252695
15:38:34 <bconoboy> is that coming up on the agenda or is now the time to discuss rc7 plan?
15:38:45 <pwhalen> #topic 1b) == F21 Aarch64 Final planning ==
15:38:52 <pwhalen> bconoboy, coming up
15:38:55 <bconoboy> :-)
15:39:15 <pbrobinson> so does anyone else have any possible blockers that we're discussed above?
15:39:20 <pwhalen> anything else we need to do ? I need to work on documentation for the release
15:39:37 <pbrobinson> release notes
15:39:55 <bconoboy> we'll be testing rc7 on seattles and mustangs today, looking for other bugs that can't be addressed as an updated package
15:40:03 <pwhalen> #info Installation documentation and Release Notes needed
15:40:15 <bconoboy> we know there is a minor stability bug in the mustang ethernet driver, but moving to a later kernel will pull in the fix for that
15:40:48 <pbrobinson> which is easily dealt with in an update
15:40:51 <pwhalen> right
15:41:14 <pwhalen> anything else needed before we release?
15:41:39 <pwhalen> anyone like to help with documentation?
15:41:46 <bconoboy> I'll help
15:42:04 <bconoboy> assuming testing goes well today, when do we release? wednesday? thursday?
15:42:05 <pwhalen> I asked, never expecting a bite! w00t
15:42:10 <pwhalen> Christmas indeed
15:42:37 <pwhalen> #topic 1c) == Are we ready to ship? ==
15:43:07 <pbrobinson> needs to be wed or thurs else it's barely worth it next year
15:43:14 <pbrobinson> bah... next wekk!
15:43:16 <pbrobinson> week!
15:43:24 <bconoboy> already have pto on the brain ;-)
15:43:28 <kylem> heh.
15:43:29 <pwhalen> I also wont be around next week
15:43:44 <kylem> most likely i will also not be around.
15:43:51 <bconoboy> Let's shoot for tomorrow, docs and testing today
15:44:00 <pwhalen> +1
15:44:10 <bconoboy> pbrobinson: I assume you're going to send the announcement when it's out.  What do you need from us by way of material?
15:44:36 <pbrobinson> well what you want in the announcement ;-)
15:45:01 * pbrobinson is pretty crap at marketing junkets
15:45:45 <bconoboy> pwhalen is mr marketing, right? :-)
15:45:58 <pwhalen> the install page usually has a blurb at the top that can be used for it
15:46:09 <pwhalen> so once we have that, likely good enough
15:46:36 <bconoboy> wfm
15:46:56 <pbrobinson> bconoboy: you're the PM ;-)
15:47:04 <pwhalen> #agreed Final testing and documentation to be done today, release F21 AArch64 GA tomorrow (17Dec14)
15:47:12 <yselkowitz> let's not forget to update the wiki this time
15:47:29 * dgilmore will be off for 3 weeks from sunday
15:47:34 <pwhalen> yselkowitz, help is appreciated.
15:47:45 <pwhalen> thanks for changing it on the weekend
15:48:14 <yselkowitz> np
15:48:26 <pwhalen> anything else?
15:48:32 <pwhalen> #topic 2) == F21 Armhfp Retrospective ==
15:48:43 <pwhalen> sorry, l realized the time here
15:49:00 <hrw> sorry for being so late
15:49:11 <pbrobinson> I think we should put up a page and email out to the list for feedback
15:49:14 <pwhalen> so I wanted to get a page up for a retrospective, but failed. I'll get something up. Idea is to add some things you felt can be improved next release
15:49:21 <pbrobinson> similar to the rest of mainline
15:49:53 <pwhalen> #action pwhalen to send out a link to the armhfp retrospective
15:50:03 <pwhalen> #topic 3) == F22 Goals ==
15:50:32 <pwhalen> We may need more time for this one, but wanted to start thinking about our goals in F22
15:50:53 <pwhalen> for example, adding fdt support to anaconda
15:51:00 <bconoboy> I'd like to see us start producing regular composes so we can test rawhide more readily before alpha.
15:51:00 <pbrobinson> again maybe one to send out to the list to gather responses and reconvene early in the new year?
15:51:27 <pwhalen> bconoboy, that is actually a large push in PA right now, start testing early so we dont kill the anaconda devs
15:51:29 <bconoboy> #idea support uboot
15:51:37 <pbrobinson> bconoboy: come to devconf
15:51:50 <bconoboy> #idea regular composes for a testable rawhide
15:51:51 <rwmjones> & building disk images regularly ..
15:51:52 <pwhalen> pbrobinson, agreed.
15:51:53 <bconoboy> pbrobinson: I am!
15:51:57 <dgilmore> this is something that should be sent to the list, and maybe different teams, the virt team may have f22 aarch64 things for instance
15:51:58 <hrw> bconoboy: cool
15:52:00 <pwhalen> does someone want to do that?
15:52:14 <dgilmore> maybe the cloud guys want to make sure openstack works etc
15:52:32 <rwmjones> dgilmore: I'm looking at that specific issue at the moment
15:52:37 <bconoboy> #idea guidance from FESCo on secondary architecture promotion requirements in light of Fedora.next
15:52:41 <pwhalen> good point, just wanted us to start thinking about it earlier
15:52:43 <pbrobinson> so I think we need to review whether we want to add Cloud and/or Workstation products
15:52:53 <bconoboy> #idea Let's discuss this at devconf, too.
15:52:57 <kylem> +1
15:53:02 <bconoboy> #link http://www.devconf.cz/
15:53:04 <dgilmore> +1 to all the above
15:53:07 <rwmjones> dgilmore: although .. do you mean running openstack or running as an image on openstack?
15:53:18 <dgilmore> rwmjones: possibly both
15:53:31 <rwmjones> right .. I'm looking at running openstack on aarch64 host
15:53:36 <pbrobinson> rwmjones: a combination of all of the above
15:54:04 <dgilmore> rwmjones: ideally it all works
15:54:05 <bconoboy> #idea Do we add cloud & workstation products for aarch64 in f22?
15:54:21 <pwhalen> #ageed F22 Goals to be discussed on the mailing list, future meeting
15:54:30 <pwhalen> #agreed  F22 Goals to be discussed on the mailing list, future meeting
15:54:57 <pwhalen> #topic 4) == Open Floor ==
15:55:14 <bconoboy> I'm going to be out for the next 2 weeks together.  When will the next fedora-arm meeting be?
15:55:36 <bconoboy> Presumably others will also be gone
15:55:37 <pwhalen> I was about to mention that, I'd say Jan 6th, 2015
15:55:49 <bconoboy> works for me
15:56:12 <hrw> I will be present on 13th Jan one
15:56:20 <pwhalen> #info Next Fedora Arm/AArch64 Status Meeting to be held Jan 6th, 2015
15:56:33 <hrw> 6th Jan is some catholic holiday which is free day
15:56:40 <pwhalen> nice
15:56:45 <pbrobinson> I'd like to make a shout out to pwhalen for the completely epic effort he made for F-21 testing. He topped out QA in terms of combined effort and that doesn't take into account aarch64
15:56:55 <pwhalen> hrw, did you find anything new testing f21 RC7?
15:57:01 <bconoboy> +1
15:57:17 <bconoboy> pbrobinson and pwhalen have been the heros of the f21 aarch64 cycle
15:57:24 <pwhalen> aw shucks, thanks guys ..
15:57:25 <ahs3> +1
15:57:34 <pbrobinson> I'll be out until the WC 12th Jan
15:58:02 <hrw> pwhalen: python took my day
15:58:03 <dgilmore> pwhalen: +1
15:58:11 <dgilmore> and pbrobinson also
15:58:34 <kylem> yeah. +1. pbrobinson and pwhalen have been super heroes the last few months.
15:58:43 <yselkowitz> +1
15:58:47 <hrw> agree as well
15:58:50 <bemk> +1
16:00:01 <pwhalen> ok, 1 minute left for the final arm meeting of the year, anything else?
16:00:09 <pwhalen> too late
16:00:16 <pwhalen> #endmeeting