15:00:35 <pwhalen> #startmeeting Fedora ARM and AArch64 Status Meeting
15:00:35 <zodbot> Meeting started Tue May 21 15:00:35 2019 UTC.
15:00:35 <zodbot> This meeting is logged and archived in a public location.
15:00:35 <zodbot> The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:35 <zodbot> The meeting name has been set to 'fedora_arm_and_aarch64_status_meeting'
15:00:35 <pwhalen> #chair pwhalen pbrobinson jlinton
15:00:35 <pwhalen> #topic roll call
15:00:35 <zodbot> Current chairs: jlinton pbrobinson pwhalen
15:00:45 <pwhalen> good morning folks, who's here today?
15:01:31 * pbrobinson o/
15:01:42 <tdawson_> Howdy
15:02:04 * jlinton waves
15:02:36 <pwhalen> alright, the usual suspects are here. lets get started
15:02:47 <pwhalen> #topic 1) ==== Userspace Status  ====
15:03:16 <pwhalen> how's user space looking? any new issues?
15:03:28 <pbrobinson> nothing new that I'm aware of
15:03:40 <pbrobinson> f30 over all seems OK
15:04:05 <pwhalen> #info No issues reported.
15:04:27 <tdawson_> That Mac address changing thing caught me by surprise, but it's not a bug ... just a feature. :)
15:04:47 <pwhalen> tdawson_, right :)
15:04:51 <pwhalen> #topic 2) ==== Kernel Status ====
15:04:54 <tdawson_> And not just for arm ... so ... I guess doesn't really need to be brought up.
15:05:47 <pwhalen> but it is unexpected
15:05:53 <pwhalen> #info F30: kernel-5.1.3-300.fc30
15:05:54 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1268565
15:06:10 <pbrobinson> it's a change of defaults, I'm not sure it was well advertised but ¯\_(ツ)_/¯
15:06:25 <pbrobinson> pwhalen: I don't believe that's an official build as yet
15:06:33 <pbrobinson> it was for test week last week
15:06:46 <pbrobinson> we should expect an official build for f30 this week
15:07:35 <pwhalen> ok, thanks
15:07:45 <tdawson_> That one is tagged as F30-updates-candidate ... so, there will be another one?
15:07:45 <pwhalen> and the next one should fix network on imx6?
15:07:55 <pbrobinson> correct
15:07:58 <tdawson_> ok
15:08:05 <pbrobinson> and also the rpi3 reboot issue
15:08:29 <pwhalen> pbrobinson, excellent! thanks
15:08:54 <pwhalen> #info F31: kernel-5.2.0-0.rc1.git0.1.fc31
15:08:54 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1269362
15:09:34 <pwhalen> I've not yet tested this, yesterday was a holiday here. Has anyone else had a chance
15:09:35 <pwhalen> ?
15:09:43 <pbrobinson> not yet
15:09:54 <tdawson_> Not I
15:09:55 <pbrobinson> but now I'm basically finished with 5.1 it's next on the list
15:10:12 <pwhalen> I will also take a look to see if it improves the armv7 builder issue
15:10:32 <pwhalen> pbrobinson, any other issues with 5.1?
15:10:37 <pwhalen> that you saw
15:11:00 <pbrobinson> nope, nothing I've seen that has regressed, over all it seems to have been quite straight forward
15:11:21 <pbrobinson> jetson tx1 seems a bit more stable, although that would not be hard with that device
15:11:36 <pwhalen> heh
15:11:40 <pbrobinson> I've tested around 20 combinations of 5.1.x
15:12:07 <pwhalen> #info Please test and report any issues to the list or #fedora-arm.
15:13:03 <pwhalen> any other kernel news?
15:13:47 <pwhalen> #topic 3) ==== Bootloader Status ====
15:13:57 <pwhalen> not aware of any issues here
15:14:19 <pbrobinson> no real change here, an upstream 2019.07-rc2 u-boot came out but I've not built it yet
15:14:34 <tdawson_> With the 5.1 kernel, there was a bunch of Rock things added.  Is that helping with the Rock960 booting straight from image?
15:14:48 <pbrobinson> should have a rc3 next week so I'll probably build that and deal with all the other bits I need to between now and then
15:14:49 <pwhalen> #info Uboot 2019.07-rc2 expected soon.
15:15:25 <pwhalen> #undo
15:15:25 <zodbot> Removing item from minutes: INFO by pwhalen at 15:14:49 : Uboot 2019.07-rc2 expected soon.
15:15:42 <pwhalen> #info Uboot 2019.07-rc3 expected next week.
15:15:46 <pbrobinson> tdawson_: I'm in progress of documenting that in it's current state where it's not straight forward to run Fedora on the emmc but you can run it
15:15:56 <pbrobinson> then as a phase 2 I'll work out how to fix t hat
15:16:42 <tdawson_> pbrobinson: Yep, I undestand the emmc issue ... just trying to boot it of an sd card for now ... with a straight Fedora image
15:16:58 <tdawson_> straight = out of the box
15:17:37 <pbrobinson> tdawson_: I'll have docs to do that by EOW
15:17:48 <tdawson_> Ya!! :)
15:18:44 <pwhalen> any other bootloader related news?
15:19:26 <pbrobinson> also looking at making our u-boot builds EBBR compliant (or at least compatible) for F-32
15:19:44 <pbrobinson> that's about it really
15:19:48 * tdawson_ particularly likes that pbrobinson said he just has to document, instead of having to tweak uboot more.
15:21:01 <pbrobinson> tdawson_: the use it without fitting in the first 2Mb has just been docs for some time
15:21:08 <pbrobinson> I just haven't had the time
15:21:29 <pbrobinson> now I can breathe a little post all the deadlines I'm circling back to do my best to unlock as much as possible
15:21:34 * satellit_ listening
15:21:37 <pbrobinson> for others to then be able to continue
15:22:12 <tdawson_> awesome ... thanks.
15:22:55 * satellit_ notes that fedora media manager does not have support for rpi3= rpi3+ or other choice on arm all see to behave the same
15:23:22 <pwhalen> #info EBBR documentation - https://github.com/ARM-software/ebbr/releases/tag/v1.0
15:23:46 * satellit_ per Martin Bříza:5/20/2019
15:24:54 <pbrobinson> satellit_: please wait until any other business to bring up off topic things
15:25:03 <pwhalen> satellit_, right, I dont they've added support for anything othe than writing out the image as is
15:25:03 <satellit_> k
15:25:21 <pwhalen> #topic 4) ==== Fedora 31 ====
15:25:42 <pwhalen> Does anyone have anything for Fedora 31?
15:25:59 <jlinton> PAC?
15:26:06 <pbrobinson> jlinton: PAC?
15:26:15 <pwhalen> man?
15:26:21 <jlinton> Pointer authentication, we could turn it on in a couple packages
15:26:26 <jlinton> and see what happens
15:27:01 <pbrobinson> jlinton: yes, we could do, do you have some general docs around it somewhere, benefits etc?
15:27:31 <jlinton> Yes, let me dig up a couple blog posts, but its part of armv8.3
15:27:44 <pwhalen> jlinton, thanks
15:27:50 <jlinton> How about https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf
15:28:02 <pbrobinson> jlinton: which generally available HW is 8.3 compat? Is there any impact on older HW?
15:28:05 <jlinton> although I think that presentation is a couple years old
15:28:33 <jlinton> I think it should be ok
15:29:28 <pbrobinson> presumably it's benefits are security, what packages were you thinking?
15:29:58 <jlinton> I haven't thought about it much more than to consider most of systemd, which is a mixed case
15:30:14 <jlinton> good because its so common, bad because if it goes wrong the machine will be unbootable
15:30:56 <pbrobinson> what about something like podman and associated cri-o stack, could assist in making containers more secure?
15:31:05 <jlinton> yah thats a good choice too
15:31:29 <pbrobinson> and less problematic than systemd in that you can recover your system
15:31:35 <jlinton> right
15:32:32 <pwhalen> agreed, sounds like a good place to start
15:32:51 <pwhalen> For Fedora 31 I wanted to discuss reducing the number of spins offered. Specifically for ARMv7. And perhaps adding a lightweight desktop for AArch64.
15:33:47 <pwhalen> we've got a bunch of spins, I'm not sure how widely they're used.
15:34:02 <tdawson_> +1 for lightweight desktop for AArch64
15:34:04 <pwhalen> In the case of SoaS, its been broken for a while and only recently came to our attention
15:34:06 <pbrobinson> we should reach out to the desktop/spin maintainers to see what their thoughts are. I'm quite happy to get HW shipped to them if they wish to retain/maintain it but they need to actively do so
15:35:20 <pbrobinson> atm XFCE is our blocking desktop for armv7, should we also add that for aarch64? Makes sense to align with a single lightweight DE for both, or maybe change it to something else and make it the same for both
15:35:54 <tdawson_> I like XFCE ... I'm good with that being the lightweight desktop
15:36:09 <pwhalen> that would make sense, I'm good with that too
15:36:25 <pwhalen> Spins currently offered for ARMv7 - Workstation, KDE, LXDE, LXQt, Mate, Minimal, SoaS, Server, Python Classroom
15:37:05 * satellit_ critical for soas on Rpi3B+ (my opinion)
15:37:10 <pwhalen> agreed, so I was thinking.. I'll send mail asking for people to volunteer to be an 'arm spin co-maintainer'.. agree to test they care about during the development cycle to ensure basic functionality. And we drop spins that dont have a co-maintainer
15:37:16 <pbrobinson> shall I send an email to devel@ and devel-announce and cc: spin maintainers to elicit wider feedback?
15:37:42 <jlinton> I'm usually running aarch64 desktops of some form, I can test them
15:37:51 <jlinton> (or fix random breakage)
15:38:11 <pbrobinson> satellit_: the sugar people need to actually test and own soas if they care about it on arm, which given the bug found in f30 shows no one to date has
15:38:58 <pbrobinson> jlinton: it's as much about getting the DE maintainers to lead on this, we'll all assist them, but they should own it on arm else we shouldn't just keep them around for the sake of it
15:39:00 <pwhalen> I've tested Sugar, but only in QEMU where it happens to work.
15:39:06 <satellit_> the fix is on google for f30 (aprez) now
15:39:11 <pbrobinson> this is as much about sharing the work load
15:39:28 <satellit_> https://drive.google.com/open?id=1keflpDVnJs4HGmsq-I2nbj7TgMrt1YWK
15:39:33 <pwhalen> satellit_, I'm happy to keep any spin that people are using
15:39:36 <pbrobinson> satellit_: yes, I know all about the fix, my point about it being broken for 10 releases is still there
15:40:36 <satellit_> i will continue test spins
15:41:17 * satellit_ https://wiki.sugarlabs.org/go/Fedora_30#Working_in_Rpi3B.2B
15:41:23 <pwhalen> for others, the kickstart for SoaS regenerates the initramfs after removing the dracut-config-generic.. so its host-only for QEMU
15:42:50 <pwhalen> satellit_, appreciate the help testing, if you want to be the 'co-maintainer' and help us avoid this for F31+.. that would be great
15:43:36 <satellit_> glad to be so designated but only can test   no programming skils at 76 yrs
15:43:42 <pbrobinson> right, and I looked at the kick starts and it comes down to the inheritance and ordering of how the included kickstart sections get executed. So straight up it's not a quick fix and I need to look closer
15:44:04 <pwhalen> satellit_, that would be a huge help to us. Just kick the tires
15:44:05 <satellit_> thanks
15:44:28 <pbrobinson> satellit_: you'll need to probably co-ordinate with Alex, I believe he's going to be taking over the SoAS lead, but it's all off topic for this meeting
15:44:34 <pwhalen> pbrobinson, yea, I looked as well and wasnt too sure how to fix it either at a glance
15:45:04 <satellit_> fyi f31 testing : https://wiki.sugarlabs.org/go/Fedora_31#Rpi-3b.2B
15:45:12 <pbrobinson> satellit_: OFF TOPIC!!
15:45:16 <satellit_> k
15:45:33 <pwhalen> hehe, but you rock for that satellit_ . will look at the kde bug you filed
15:45:59 <pwhalen> anything else for f31?
15:46:59 <pwhalen> #topic 5)  == Open Floor ==
15:47:28 <pwhalen> Does anyone have anything for open floor?
15:47:30 * satellit_ fyi: https://wiki.sugarlabs.org/go/Fedora_30#Fedora_MediaWriter
15:48:20 <pwhalen> satellit_, as is media writer should work for rpi2/3
15:48:52 <pbrobinson> satellit_: media writer will work for all supported RPi devices (v2 and all 3 series devices)
15:49:25 <satellit_> https://wiki.sugarlabs.org/go/Fedora_30#Fedora_MediaWriter  error in link correspondence with mbriza
15:49:27 <pbrobinson> you don't have to specify any specific model as they all boot the same way and detect which device it is and adjust bits as needed
15:50:24 * satellit_ be nice to know unsuppored for variou models  made me test 3 setting for bad soas arm
15:50:26 <pbrobinson> satellit_: the comments in that wiki don't make sense
15:50:52 <satellit_> asks mbriza...
15:51:04 <pbrobinson> what is the bug that is causing the issue? Kernel versions etc are completely irrelevent in this context
15:51:21 <satellit_> so I found out later
15:51:47 <pbrobinson> satellit_: OK, just mention it on the arm or sugar channels
15:52:02 <satellit_> k
15:53:01 <pwhalen> satellit_, as a testing MVP, I am happy you now have arm hardware
15:53:17 <satellit_> : )
15:53:45 <pwhalen> anything else for open floor?
15:56:21 <pwhalen> #endmeeting