15:00:19 <pwhalen> #startmeeting Fedora ARM and AArch64 Status Meeting
15:00:19 <zodbot> Meeting started Tue Feb 26 15:00:19 2019 UTC.
15:00:19 <zodbot> This meeting is logged and archived in a public location.
15:00:19 <zodbot> 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:19 <zodbot> The meeting name has been set to 'fedora_arm_and_aarch64_status_meeting'
15:00:19 <pwhalen> #chair pwhalen pbrobinson
15:00:19 <pwhalen> #topic roll call
15:00:19 <zodbot> Current chairs: pbrobinson pwhalen
15:00:28 <pwhalen> morning folks, who's here today?
15:00:53 <pwhalen> good morning jlinton
15:00:53 * pbrobinson o/
15:01:25 <jlinton> morning
15:01:33 <tdawson> Hi
15:03:54 <pwhalen> looks like we've got the usual suspects, lets get started.
15:04:02 <pwhalen> #topic 1) ==== Userspace Status  ====
15:04:14 <pwhalen> any new/old  user space issues?
15:04:20 * pbrobinson tries to remember the issues from last week
15:04:31 <pbrobinson> jlinton: how goes firefox?
15:04:46 <jlinton> firefox, i think ive got it building  rpm now
15:05:04 <jlinton> although the koji instance is very different than my container
15:05:32 <pbrobinson> yea, I bet
15:06:01 <pbrobinson> jlinton: did you see this mozjs on aarch64 one? (sorry, I know another not so favourite one) https://bugzilla.redhat.com/show_bug.cgi?id=1676292
15:06:05 <jlinton> The rust binaries are smaller
15:06:31 <jlinton> so i don't need the rust hacks
15:06:49 <jlinton> I saw the mozjs failure, but it looked to be moving along on its own
15:08:34 <jlinton> Anyway, the container builds are just subtly different
15:08:54 <jlinton> Its probably worth tracking down why
15:09:32 <pbrobinson> yea. the mozjs was FYI
15:09:58 <pbrobinson> on the rust size/hacks, I don't follow completely
15:14:01 <pwhalen> perhaps we lost jlinton
15:14:05 <pwhalen> any other user space issues?
15:14:35 <pbrobinson> none I'm particularly aware of
15:14:40 <jlinton> I'm here, I was just trying to say the container rust objects were larger than the koji ones
15:14:53 <jlinton> which was causing other failures
15:15:26 <jlinton> There is that other defect I opened about uefi framebuffers not being tagged as master-of-seat
15:16:05 <jlinton> Its probably on purpose, but now that gdb/sddm pay attention to CanGraphical it makes it appear that the machine hangs if a graphics driver fails to start
15:16:58 <pbrobinson> jlinton: yea, I moved that to systemd, not had a chance to look further
15:18:12 <pbrobinson> jlinton: in the case of RPi it should move from efifb -> vc4 for that, and it worked for me the last I tested  it with gdm, but I do need to test f30 on aarch64 gnome
15:18:25 <jlinton> https://bugzilla.redhat.com/show_bug.cgi?id=1679801
15:18:59 <jlinton> yah, this was caused by the DT that the upstream uefi causing vc4 failures
15:19:10 <jlinton> but of course,  even when I updated it, vc4 didn't want to start.
15:19:28 <jlinton> that just made it worse, although I used a 5.0 DT with a 4.20 kernel
15:19:35 <jlinton> .....
15:19:49 <pbrobinson> not sure there's enough difference there to cause issues
15:20:29 <pbrobinson> jlinton: was that using the tianocore with the RPI when you say "upstream uefi"
15:20:34 <jlinton> Yes
15:21:30 <pbrobinson> OK
15:23:00 <pwhalen> jlinton, thanks for the update and moving that along
15:23:06 <pwhalen> anything else?
15:23:48 <pwhalen> #topic 2) ==== Kernel Status ====
15:23:59 <pwhalen> #info F31: kernel-5.0.0-0.rc8.git0.1.fc31
15:24:00 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1215938
15:24:15 <pwhalen> I see pbrobinson just started an f30 build as well.
15:24:26 <pbrobinson> well it's almost finished
15:25:17 <pwhalen> OK, the f31 build looks good so far, anyone seeing any issues?
15:26:25 <pwhalen> #info F30 build of kernel-5.0.0-0.rc8.git0.1 should be available in Koji shortly
15:26:58 <pwhalen> #info Please test and report any issues to the list or #fedora-arm.
15:28:41 <pwhalen> #topic 3) ==== Bootloader Status ====
15:28:58 <pbrobinson> I think most is OK here
15:29:21 <pwhalen> I dont think I've tested that new uboot much, but will get to it this week. Where I have tested its worked ok.
15:29:50 <pbrobinson> I'm working this week to try and get thing last few bugs around grub2/uefi on armv7 to the testing start where we have at least a nightly minimal to enable wider testing
15:30:10 <pbrobinson> overall the testing I've done it seems fine
15:30:21 <pbrobinson> working to get it on more of my devices in the next few days
15:30:51 <pwhalen> excellent, let us know how we can assist
15:31:18 <pwhalen> #topic 4) == F30 ==
15:31:30 <pwhalen> #info Latest nominated nightly - https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
15:31:30 <pwhalen> #info F30 Beta Blockers
15:31:30 <pwhalen> #link https://qa.fedoraproject.org/blockerbugs/milestone/30/beta/buglist
15:32:16 <pbrobinson> anything that affects Arm?
15:32:17 <pwhalen> the aarch64 disk issues we talked about last week are now fixed, its using bls now and also not selecting 'System setup' as default
15:32:33 <pbrobinson> awesome
15:32:38 <pwhalen> I'm not aware of arm specific issues
15:32:54 <pbrobinson> what about generic issues that are seen on arm?
15:33:47 <pwhalen> we had some compose issues last week in f30. Cloud was failing on aarch64 due to network issues I couldnt reproduce. The builders were updated and rebooted and all is well
15:34:26 <pwhalen> I've not really seen any generic issues either
15:35:38 <pwhalen> so we're looking OK so far
15:37:05 <pwhalen> anything else for f30?
15:37:39 <pbrobinson> major features need to be testable by March 5th
15:38:07 <pwhalen> one week from today
15:38:28 <pwhalen> #topic 5)  == Open Floor ==
15:38:46 <tdawson> I had one or two questions for open floor.
15:39:38 <tdawson> Other than double the work testing, is there a reason why the spings are for armhfp only, and not aarch64 also?
15:40:02 <tdawson> spins, not spings
15:41:04 <pwhalen> we enabled them all in armhfp, and learned from our mistake. We'd like spin maintainers to engage with us if they would like it available on aarch64.
15:41:12 <pbrobinson> tdawson: because when we did armhfp we enabled all
15:41:49 <pbrobinson> and in aarch64 we decided to just enabled minimal plus edition bits and let the maintainers of other artefacts reach out
15:42:02 <pbrobinson> when they were prepared to test and maintain them
15:42:42 <tdawson> OK, makes sense ... so there isn't a real 'firmware is only 32 bit' issue, it's mainly workload
15:43:12 <pbrobinson> what do you mean by a 'firmware is only 32 bit' issue?
15:43:54 <tdawson> pbrobinson: I don't know ... I just didn't know if there was something specific to 32 bit that was holding it back ... firmware was just what popped into my head
15:44:16 <pbrobinson> nope, all down to people to do the work
15:44:24 <tdawson> OK, good to know
15:44:54 <tdawson> So if something works on 32 bit, and I want to do a aarch64 bit spin, it usually should work.
15:45:25 <pwhalen> it should, I've done test spins of lxde for myself
15:46:06 <tdawson> That answers my question, thanks
15:46:19 <pbrobinson> tdawson: in most cases yes, it comes a little to if the HW support is there, but no different to specific devices in the 32 bit space
15:46:52 <pbrobinson> if you're unsure just ask on one of the various arm communication channels for clarification
15:47:07 <tdawson> pbrobinson: Will do.  Thank you
15:47:10 <pbrobinson> but generally it should all work fine on aarch64
15:49:31 <pwhalen> #endmeeting