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