15:02:22 <pwhalen> #startmeeting Fedora ARM & AArch64 Status Meeting
15:02:22 <zodbot> Meeting started Tue Dec  9 15:02:22 2014 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:32 <pwhalen> attempting to, through my lag
15:02:44 <pwhalen> #chair pwhalen jonmasters bconoboy pbrobinson dgilmore dmarlin hrw jsmith
15:02:44 <zodbot> Current chairs: bconoboy dgilmore dmarlin hrw jonmasters jsmith pbrobinson pwhalen
15:02:51 <bconoboy> .fas blc@
15:02:52 <zodbot> bconoboy: blc '' <blc@redhat.com>
15:02:55 <jsmith> Buenos días :-)
15:02:56 <pwhalen> #topic roll call
15:03:05 <hrw> .fasinfo juszkiewicz
15:03:07 <pwhalen> .fas pwhalen
15:03:09 <zodbot> hrw: User "juszkiewicz" doesn't exist
15:03:12 <yselkowitz> .fas yselkowitz
15:03:12 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
15:03:17 <bconoboy> .fasinfo blc
15:03:17 <zodbot> yselkowitz: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
15:03:20 <zodbot> bconoboy: User: blc, Name: None, email: blc@redhat.com, Creation: 2008-06-20, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active
15:03:22 <pwhalen> thanks for coming on short notice all
15:03:25 <hrw> .fas hrw
15:03:26 <zodbot> bconoboy: Approved Groups: @gitkernel-arm64 fedorabugs packager +gitarm-boot-config +aarch64 cla_fedora cla_done cla_fpca gitarm
15:03:28 * pbrobinson is here
15:03:30 <zodbot> hrw: hrwillett 'Herman R Willett' <hrwillett@gmail.com> - vikaashrworld 'Vikash Kumar' <vikashrworld@gmail.com> - hrw 'Marcin Juszkiewicz' <mjuszkiewicz@redhat.com> - chrwhy 'Stephen Chen' <chrwhy@gmail.com>
15:03:44 <Corey84-> .fas corey84
15:03:45 <zodbot> Corey84-: corey84 'Corey84' <sheldon.corey@gmail.com>
15:03:50 <hrw> one day I will learn how to selfintroduce through zodbot
15:04:04 <Corey84-> hrw have a fas acct?
15:04:08 <pwhalen> before we get started, we plan on doing this meeting now once a week
15:04:08 <hrw> .fas mjuszkiewicz
15:04:09 <zodbot> hrw: hrw 'Marcin Juszkiewicz' <mjuszkiewicz@redhat.com>
15:04:14 <hrw> that's best
15:04:32 <pwhalen> hopefully it works for all.
15:04:43 <pwhalen> #topic 1) ==== Fedora 21 Status (armhfp) =====
15:04:53 <pwhalen> #info Fedora 21 Installation Documentation
15:05:01 <pwhalen> #link https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation
15:05:33 <pwhalen> I've updated the installation docs, including all the hardware I have. If there is something you have not listed, please feel free to add to the wiki
15:05:56 <yselkowitz> the workstation image is in a different location
15:05:56 <pwhalen> any corrections needed, go ahead and edit, I will not be offended. I promise.
15:06:31 <pwhalen> yselkowitz, do i have a bad link?
15:06:51 <yselkowitz> pwhalen, no, everything else but workstation is at that link
15:07:06 <yselkowitz> don't know why, but workstation (gnome) is at http://fedora.mirror.nexicom.net/linux/releases/21/Workstation/armhfp/Images/
15:07:10 <pwhalen> ah, right ok .. will need to make an edit there
15:07:34 <pwhalen> #action pwhalen to add appropriate link for Workstation image
15:07:56 <pwhalen> #info Fedora 21 released today!
15:07:58 <yselkowitz> then mention Workstation as an option for TYPE=
15:08:13 <pwhalen> will do
15:09:00 <pwhalen> anything else we should talk about for F21?
15:09:05 <pwhalen> armhfp anyways
15:09:09 <bconoboy> well
15:09:14 <yselkowitz> are the "known issues" current?
15:09:16 <bconoboy> just congrats everybody for getting it out today :-)
15:09:21 <Corey84-> pwhalen,  yselkowitz  with the release and   fp.o > gf.o   some redirects may be  causing that
15:09:32 <pbrobinson> yes, +1 to what blc says
15:09:40 <pwhalen> w00t
15:09:58 <pwhalen> but dont too excited.. we're starting on F22 right away :)
15:10:13 <pwhalen> thanks yselkowitz
15:10:22 <pbrobinson> also a 3.18.0 build should land in rawhide today so if people have some cycles it would be great to start to get some testing on it
15:10:32 <pbrobinson> I've tested a number of devices
15:10:34 <pwhalen> for known issues, we should add anything you have come across not listed.
15:11:15 <pbrobinson> #info common bugs for F-21 are listed here https://fedoraproject.org/wiki/Common_F21_bugs
15:11:42 <pwhalen> yselkowitz, took out the bbb uboot issue, thats been closed
15:11:49 <pwhalen> but all else is current, i think
15:11:55 <pbrobinson> any updates or tweaks to that list please make sure it's added, or check with pwhalen and myself
15:12:36 <pwhalen> #info Testing of F22 has begun
15:12:43 <pwhalen> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_20141208_Summary#ARM_disk_images
15:13:14 <pwhalen> the idea is to get an early start on issues so we dont kill the anaconda team
15:13:56 <Corey84-> im on 3.18.rc6 with 21  atm  seems fine her
15:13:59 <Corey84-> here*
15:14:07 <pwhalen> Corey84-, cool, what device?
15:14:26 <Corey84-> my buddies Rpi
15:14:30 <Corey84-> b+
15:14:53 <pbrobinson> the only known issue I'm aware of atm in the anaconda/lorax/blivet stack is dtb/uboot support for aarch64. bconoboy is there a BZ for that?
15:14:54 <Corey84-> its not too busy tho might be able to stress it thurs/fri when im there again
15:15:07 <pwhalen> pbrobinson, not at aarch64 yet :)
15:15:20 <pbrobinson> Corey84-: RPi is irrelevant for mainline Fedora
15:16:00 <pwhalen> ok, we can move on to the new shiny if we're all done with armhfp.. anything else worth talking about before?
15:16:13 <pbrobinson> I don't believe so
15:16:21 <bconoboy> pbrobinson: There's a python-blivet bug
15:16:38 <pbrobinson> bconoboy: is there a RHBZ?
15:16:41 <pwhalen> #topic 2) ==== Fedora 21 (aarch64) ====
15:16:41 <pwhalen> #topic 2a) == Open Bugs ==
15:16:43 <bconoboy> There is, looking for it
15:17:39 <pwhalen> bconoboy, shall i wait?
15:17:51 <bconoboy> one sec
15:18:18 <bconoboy> move on, it'll take a couple minutes
15:18:31 <pwhalen> #info New Lorax build needing karma
15:18:32 <pwhalen> #link https://admin.fedoraproject.org/updates/FEDORA-2014-16415/lorax-21.32-1.fc21
15:19:06 <pwhalen> I was trying to test this one yesterday but had local issues, pbrobinson do you plan on using this for the new compose?
15:19:16 <pwhalen> then we can all leave karma on it
15:19:16 <pbrobinson> pwhalen: i'll be doing a RC6 build in the morning (Aus time) with the new lorax for testing. Any other issues need to be addressed over RC5?
15:19:32 <pbrobinson> I'll pull it into a bleed repo
15:19:43 <pwhalen> nice
15:19:48 <hrw> https://bugzilla.redhat.com/show_bug.cgi?id=1170289 (shim spec file hardcodes DEFAULT_LOADER=grubx64.efi even for aarch64)?
15:20:26 <pjones> Actually already fixed in the package, but there's no way for me to actually fix it in the repo tag, because we automatically untag things that don't match the x86_64 version.
15:20:26 <pwhalen> #action ALL: Test RC6, if working leave karma - https://admin.fedoraproject.org/updates/FEDORA-2014-16415/lorax-21.32-1.fc21
15:20:34 <pwhalen> trying to go through these in order here folks
15:20:34 <pbrobinson> hrw: we need pjones to do a mainline x86 build to be able to pull that fix into aarch64 builds
15:20:41 <hrw> pbrobinson: ok
15:20:44 <pjones> pbrobinson: except I can't reasonably do that.
15:20:56 <pwhalen> would we not add to bleed?
15:21:02 <pbrobinson> nope
15:21:27 <bconoboy> Okay, found it
15:21:29 <hrw> pwhalen: RC6 iso is not yet on compose
15:21:29 <pwhalen> meh, okay. work around is to not use shim
15:21:35 <pbrobinson> pwhalen: the standard for pulling anything into bleed is it needs to be in updates-testing and going through testing
15:21:39 <pjones> in which case we don't get e.g. fallback
15:21:54 <pbrobinson> pjones: what sort of fallback?
15:21:54 <pjones> which... I guess you can choose not to have, but it kind of makes your platform junky.
15:21:59 <pwhalen> pbrobinson, not going to fight ya, just unfortunate
15:22:17 <pjones> fallback.efi, the thing that fixes boot entries in the case where you've lost efi boot variables or moved the disk to another machine
15:22:27 <pbrobinson> I don't see what shim provides us without secure boot
15:22:45 <pjones> then you're not paying any attention.
15:23:07 <pjones> I *just told you*.
15:23:31 <pwhalen> hrw, when RC6 is of course :)
15:23:38 <pbrobinson> pjones: what is "fallback"
15:24:05 <pjones> the thing I explained one line after the last time you asked that, 4 lines ago in this scrollback.
15:24:25 <pjones> er, well 5.  but still.
15:25:02 <pbrobinson> pjones: why doesn't efibootmgr do that then?
15:25:22 <pjones> because efibootmgr is a linux utility that doesn't run from under UEFI?
15:25:56 <bconoboy> pjones: Can we ship f21 for aarch64 without resolution on shim?  It sounds like this is a failsafe
15:26:23 <pjones> bconoboy: it means we need to go back and /undo/ what's in anaconda and lorax, doesn't it?
15:26:25 <hrw> pwhalen: please make f21 rc6 bootable...
15:26:40 <pbrobinson> pjones: I'm not an uEFI expert, hence the reason I'm asking these questions..... no need to be rude
15:26:41 <pjones> (seriously why can't we just tag a different %{release} of the package into the repo?  that's all we need to do.)
15:27:25 <bconoboy> pjones: It sounds like doing so runs afoul of a policy wihch has technical enforcement mechanisms we'd need to turn off
15:27:56 <pjones> I don't honestly think that's a fair categorization, but you're right we'd need to stop doing something we're doing.
15:28:42 <pbrobinson> pjones: it's long been a requirement that all builds must be in mainline and we build off those
15:28:55 <bconoboy> pbrobinson: Is this just a policy question or is there a technical limitation here? I'd hate to rollback functionality.
15:29:30 <pbrobinson> bconoboy: there's a number of reasons and if we do it for one package where do we stop? We may as well just fork
15:29:47 <bconoboy> pbrobinson: We stop at exactly this 1 package
15:30:24 <bconoboy> This is the very very first aarch64 release, I think it's reasonable to bend slightly.  Perfection is the enemy of the good and all that.
15:31:21 <pbrobinson> bconoboy: but why, where and how do we document exceptions in general and then apply it to this package
15:32:06 <pbrobinson> and is it an exception for F-21 because the issue missed GA and is it fixed moving forward or is it an ongoing exception?
15:32:43 <pjones> it won't be ongoing; once we actually have /the right things/ in the package for both arches, the next time we do an upstream release and do a build for that, they'll fall into sync naturally.
15:32:56 <pjones> but unlike many packages, that's not something we can casually do
15:33:41 <bconoboy> pbrobinson: This really sounds like a PA/SA issue that only presented after PA locked down.  If we need a policy development for how to handle these issues then let's use this as a test case for how to handle it
15:33:48 <pbrobinson> well that's fine and if that's the case we can look at a one off exception which I'll have to do a bunch of work to work around manually but no one has actually stated until now that I've seen
15:35:15 <bconoboy> So I'd propose this as a starting point
15:35:45 <bconoboy> Sometimes we have to make changes after GA freezes, it's the nature of being an SA
15:35:52 <bconoboy> s/GA/PA/
15:35:54 <pjones> I think I did actually say that to you last thursday, but admittedly not in those specific terms.
15:36:05 <bconoboy> But we have to ensure we converge with PA
15:36:11 <pbrobinson> bconoboy: pjones: if it's a one off exception I can deal with this, but if it's ongoing and permanent we need to deal with it properly.... helps to provide all the story
15:36:57 <bconoboy> Convergence means all instances are one-offs that will automatically be converged upon in an acceptable period of time.
15:37:00 * masta looks in
15:37:04 <pjones> It'll be an exception for this release only.  I'm not saying there'll never be any other case where we have exceptions due to complexity here, but /this/ will certainly not be ongoing.
15:37:14 <bconoboy> We definitely have that in this case.
15:37:33 <pbrobinson> pjones: to be fair last week I was working 8am to 3am all week to get F-21 to a point it could actually go GA today, plus EL beta and two secondary arches.... I've been under a little bit of pressure and even with that specific conversation it still wasn't clear to me
15:37:50 <pjones> pbrobinson: okay.
15:38:28 <bconoboy> pbrobinson: We totally appreciate how much work you've been in this week, even today, and really don't want to add to it, quite the opposite
15:38:52 <pbrobinson> pwhalen: can you add appropriate notes to the meeting that we'll include (what ever shim NVR) and include notes it's a special exception for this release please
15:39:15 <pbrobinson> pjones: what NVR for shim and shim-signed do we need?
15:39:17 <pwhalen> sure, whats the nvr for this one?
15:39:19 <pjones> sure; give me just a minute to figure that out.
15:39:27 <pwhalen> yea, i found it at one point
15:39:37 <pbrobinson> and I'll add it to RC6
15:39:49 <pwhalen> shim-0.8-5?
15:40:21 <pjones> give me just a minute to make sure I tell you the right answer.
15:40:46 <pbrobinson> pjones: thanks
15:40:50 <bconoboy> should we move on?
15:41:07 <pbrobinson> yes, pwhalen can add the note once we have the info
15:41:24 <pjones> pwhalen: shim-0.8-2.fc21 and shim-signed-0.8-5 (those are the srpm/build package names)
15:41:44 <bconoboy> #agreed F21 for aarch64 will use shim-0.8-2.fc21 and shim-signed-0.8-5
15:41:52 <pwhalen> thanks bconoboy
15:42:00 <pwhalen> #info Installer unable to add bootloader EFI entry on AArch64
15:42:00 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1151571
15:42:33 <pwhalen> this bug was closed, but the issue persists. I believe a bug in tianocore. how do we plan to track this?
15:42:49 <pbrobinson> #info the inclusion of shim-0.8-2.fc21 and shim-signed-0.8-5 is an exception of different NVR from primary for F-21 only and will be fixed moving forward
15:42:52 <hrw> pwhalen: can you add note on how to reproduce it with rc5?
15:43:04 <pwhalen> i did, above the comment where you closed it
15:43:13 <hrw> ah, sorry
15:44:45 <pwhalen> hrw, no worries, just dont want to lose it. I was going to reopen but think its tianocore we need to look at
15:44:46 <bconoboy> pwhalen: We should ask the firmware vendor to fix.  Oh crap, that's us.
15:44:55 <pwhalen> :)
15:44:58 <hrw> 'D
15:45:17 <bconoboy> Not really sure why it's closed if it's still an issue
15:45:25 <pbrobinson> bconoboy: wasn't that the point of uEFI.... it would never be us ;-)
15:45:39 <bconoboy> pbrobinson: A temporary set back...
15:46:00 <pwhalen> bconoboy, can we file bugs on tiancocore in bugzilla?
15:46:28 <pbrobinson> pwhalen: we don't ship it in Fedora so no
15:46:35 <pbrobinson> so what's next on the list?
15:46:43 <pwhalen> ok
15:46:56 <pwhalen> #info Bundling exception for coffee-script
15:46:56 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1166489
15:47:00 <pbrobinson> bconoboy: how is the vfat driver writing for tiancocore going?
15:47:16 <pwhalen> this one we decided can be ignored for F21, but I also wanted it in our logs for tracking
15:47:36 <pwhalen> anything to add on this one? or move on
15:47:38 <bconoboy> pbrobinson: it's not getting priority attention yet, probably nut until january.  We really should get it done during f22 development though, it would be super useful.
15:48:09 <pwhalen> #info No KVM virtualization on APM Mustang and other boards (3.17.4/f21 and 3.18-rc/f22)
15:48:09 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1165290
15:48:12 <yselkowitz> pwhalen, between that and the execjs bug, rails will be hard to install
15:48:19 <pbrobinson> bconoboy: well we can't do uEFI aarch64 virt on anything OOTB until we do
15:48:24 <yselkowitz> or at least run at full strength
15:48:48 <pwhalen> yselkowitz, something we need to get fixed for f22, but i think its a little too late for us in f21
15:48:49 <bconoboy> pwhalen: That's actually a firmware bug, but I thought we introduced a workaround in the kernel
15:49:03 <pjones> pbrobinson: if we're only concerned with our OS, we could actually work around that, but I'm not convinced it's not a dumber option.
15:49:33 <pjones> (that is, no other OS booting in the vm)
15:49:43 <bconoboy> #info This is a firmware bug, a one line workaround has been introduced into the aarch64 kernel.  To be tested in next RC
15:49:55 <pbrobinson> pjones: by our OS do you mean Fedora plus derivatives or Linux in general?
15:50:03 <pjones> yeah.
15:50:24 <pbrobinson> pjones: that wasn't a "yeah" question ;-)
15:50:33 <masta> hehe
15:50:39 <pjones> uh... okay?  Seemed like it was phrased as one, so rephrase? ;)
15:50:45 <pwhalen> #info aarch64: anaconda in VM dies with "SystemError: Could not determine system architecture." because blivet assumes aarch64 always has EFI
15:50:45 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1128341
15:50:46 <pjones> Oh, I see.
15:51:05 <bconoboy> So that is the "uboot bug"
15:51:35 <bconoboy> Basically python-blivet things all aarch64 hosts are EFI. Expanding that to support uboot would require enhancements to the package.
15:51:40 <pjones> pbrobinson: point being if we don't care about "generic" support from people not expecting things, we can go apple's route and use a different FS for the ESP.  But a) that's harder to support long term for us, b) still requires writing our own FS driver, though it may be one with less baggage in some ways (still probably more work.)
15:51:41 <bconoboy> (If I'm reading the BZ correctly)
15:52:02 <pbrobinson> pjones: well I see there's two options "Fedora and derivatives (IE RHEL etc)" or "linux in general (ie Debian/Ubuntu etc)" but you could maybe one day add the third option if Windows ever appears (which is what I'd see as the no answer"
15:52:02 <pjones> pbrobinson: also c) technically nonstandard
15:53:21 <bconoboy> guys, are we talking uboot or tianocore right now?
15:53:22 <pwhalen> bconoboy, that was my understanding.
15:53:25 <pjones> pbrobinson: anyway, probably not worth serious consideration given the current state.
15:53:40 <bconoboy> let's do uboot, then tiaocore if appropriate
15:53:57 <pbrobinson> pjones: agreed
15:54:22 <bconoboy> So, what do we want to do? I'd like to see fedora work on as many platforms as possible, which means including uboot support
15:54:25 <pbrobinson> bconoboy: OK, that needs the above python-blivet bug fixed correct?
15:54:45 <bconoboy> Those samsung aarch64 development boards use a third bootloader, too, so going wide is going to take some doing
15:54:52 <pwhalen> ugh
15:55:11 <pbrobinson> bconoboy: yes, like kvm/xen we support both in Fedora and uEFI is only a requirement for the A64 server platform and not a lot of others where u-boot will still be the standard
15:55:12 <bconoboy> pbrobinson: Yes, though calling it a bug is probably a misnomer, it's more of an design decision
15:55:34 <bconoboy> So we need to work with the anaconda team to decide on something bigger
15:55:41 <pbrobinson> bconoboy: I was keeping it simple
15:56:09 <pbrobinson> bconoboy: we've got 5 mins left, I think we can take this to the bug/list as it's ongoing, but we need the support
15:56:35 <pwhalen> agreed. move on for now, discuss again next week
15:56:47 <bconoboy> #agree Defer to next week
15:56:59 <bconoboy> I'll mail dlehman
15:57:27 <pwhalen> #topic 2b) == F21 Aarch64 Deliverables & Planning ==
15:57:47 <pwhalen> #info pbrobinson to compose RC6 for testing
15:57:53 <pwhalen> shall we also revist this next week?
15:58:34 <pwhalen> #topic 3) ==== OPen Floor ====
15:58:56 <pwhalen> anything left we can discuss in 2 minutes?
15:59:17 <masta> hehe
15:59:36 <hrw> I would like to have fedora21 bootable dvd iso
16:00:02 <masta> hrw: that should be doable, I can show you how to make one
16:00:15 <hrw> masta: I built one by hand
16:00:16 <bconoboy> Just a big thank you to pbrobinson for driving f21 aarch64 koji-shadow the last year.  He's gotten us a long, long way.
16:00:19 <pbrobinson> hrw: I believe that should have been fixed with rc5 which used the newer lorax, did you test RC5?
16:00:32 <masta> yeah! thanks pbrobinson !
16:00:36 <hrw> pbrobinson: tested.
16:00:47 <pbrobinson> masta: no, it needs to be done in lorax/pungi and the compose process
16:00:59 <pwhalen> #endmeeting