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