16:30:05 <nirik> #startmeeting Fedora Mobility SIG
16:30:05 <zodbot> Meeting started Mon Feb 14 16:30:05 2022 UTC.
16:30:05 <zodbot> This meeting is logged and archived in a public location.
16:30:05 <zodbot> The chair is nirik. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:30:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:05 <zodbot> The meeting name has been set to 'fedora_mobility_sig'
16:30:05 <nirik> #meeting_name fedora_mobility_sig
16:30:05 <nirik> #chair torbuntu pbrobinson _Yoda_
16:30:05 <nirik> #topic init process
16:30:05 <zodbot> Current chairs: _Yoda_ nirik pbrobinson torbuntu
16:30:35 <torsh[m]> Hello !
16:30:43 <nirik> who all is around today for a nifty fedora mobility meeting?
16:31:02 * torsh[m] waves
16:31:20 <yoda[m]> Sorry - I only have 3 minutters
16:31:55 <nirik> 3minutes? ok, we will go quick... :)
16:33:35 <nirik> I guess lets go ahead and start.
16:33:38 <nirik> #topic remix status / issues / plans
16:33:47 <nirik> so where are we with pp and ppp remixes?
16:34:11 <nirik> we still have the old dec image up for pp...
16:34:24 <torsh[m]> pp is still basically the same. Some nice updates happened to most of the packages lately though so that's nice. The kernel we use has keyboard drivers baked in.
16:34:41 <yoda[m]> Plasma-settings just updated and Onuralp have made a new build for the wifi settings, that should work
16:34:56 <torsh[m]> There was work being done to get some pipelines running in github to generate images. I forget where that is at.
16:35:03 <yoda[m]> This makes most work for both pƄ and ppp with Plamo
16:35:05 <nirik> cool.
16:35:09 <torsh[m]> (so then it won't be me remembering/making time to generate the image manually and upload heh)
16:35:30 <nirik> yeah, I saw wifi wasn't really doing anything in the plasmo settings thing
16:36:21 <yoda[m]> Sound is still missing on ppp-plamo - I Continental to investigate
16:36:24 <nirik> are there still a bunch of plasmo packages to review?
16:36:48 <be[m]> hello
16:36:57 <yoda[m]> Yes - but they are all included in image from COPR
16:37:33 <nirik> hey be[m]. welcome
16:37:42 <yoda[m]> Work calls - see ya
16:37:47 <be[m]> took a few minutes for Matrix to let me in the room
16:37:54 <nirik> if we have a list or tracker I can try and do some... been swamped lately, but can try
16:38:34 <be[m]> Has anyone been working on packaging the Pine64 PPP kernel?
16:38:59 <nirik> be[m]: not that I know of, but that would be nicer than megi kernel for ppp IMHO
16:39:15 <torsh[m]> I thought there was someone taking a stab at a copr for it?
16:39:24 <be[m]> I started looking into it, though the kernel is probably the most complex package to get started with Fedora packaging šŸ˜…
16:39:43 <torsh[m]> It has been on my list to get into copr, but I've been really buried at work.
16:39:52 <nirik> yeah, it's big and crazy
16:40:11 <be[m]> So the Fedora kernel has this complex system to autogenerate the RPM spec
16:40:35 <be[m]> I don't think we need to worry about that. My idea was just to copy the generated RPM spec and change where it gets the source code
16:41:06 <nirik> sure, fine for a copr version...
16:41:14 <nirik> I guess we should move to...
16:41:25 <nirik> #topic fedora mainline plans
16:41:44 <be[m]> specificly this file https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec
16:42:09 <nirik> I think we can keep packaging up userspace and see how kernel bits end up going...
16:42:12 <be[m]> I gotta learn how to use mock for crosscompiling packages
16:42:13 * nirik nods
16:42:46 <be[m]> Tangentially, the last few days I've been working on figuring out how to crosscompile Rust to Windows, macOS, and ARM64 Linux
16:43:15 <nirik> it's pretty easy to get mock to cross build. Just need the right qemu and a setting or two I think.
16:43:48 <be[m]> yeah building my Rust project in QEMU takes 2 hours... working on alleviating that, but anyways, back to the Pinephone Pro
16:43:50 * pbrobinson is late
16:44:11 <be[m]> hello @probinson
16:44:12 <torsh[m]> šŸ‘‹
16:44:14 <nirik> the next few months are going to be exciting. ;)
16:44:17 <nirik> hey pbrobinson
16:44:33 <torsh[m]> Was there something I missed as far as news, nirik?
16:44:42 <be[m]> I'm wondering if it's too early to start making a package group for Phosh and Plasma Mobile upstream?
16:45:25 <nirik> well, I just meant as far as stuff gets upstreamed for ppp and ability to use it somewhat under vanilla kernel... I think that will definitely happen in the next few months...
16:45:36 <nirik> be[m]: we already have a phosh-desktop one.
16:45:44 <torsh[m]> Oh, that is super exciting indeed!
16:45:47 <nirik> can easily add a plamo
16:45:48 <be[m]> oh nice
16:46:17 <nirik> BTW, on the plasmo image on my ppp... I tried to install phosh-desktop and... it crashes. I haven't really looked into why yet tho
16:46:28 <pbrobinson> we already have a comps group for phosh
16:46:30 <be[m]> yep `dnf groupinstall phosh-desktop` pulls in a bunch of packages
16:46:49 <pbrobinson> from a people side of things it depends on how many people are actively participating
16:47:22 <nirik> yeah. I hope the folks that the fedora council got ppp's for are able to jump in and contribute...
16:47:23 <be[m]> so... image generation. Can ImageBuilder output a raw UEFI bootable image currently?
16:48:01 <nirik> be[m]: I was going to reply to your email, but I decided it would be silly too... since my answer is "no idea, never used ImageBuilder, ask them" :)
16:48:01 <pbrobinson> yes, mine arrived and I've got it out of the box
16:48:35 <nirik> I think I saw raw support in the upstream code, but I haven't really looked at ImageBuilder much at all. ;(
16:48:53 <be[m]> I'm confused because I didn't see that as an option when listing the available output formats locally
16:48:55 <pbrobinson> so there's work around making IB more straight forward to feed in random image definitions
16:49:05 <be[m]> maybe it's just in upstream code but not the F35 package yet
16:49:10 <nirik> be[m]: could be.
16:49:18 <pbrobinson> be[m]: some of the work is only just landing upstream now
16:49:28 <be[m]> ah, that explains it
16:49:40 <be[m]> so IIUC ImageBuilder doesn't use Kickstarts at all?
16:49:50 <be[m]> but this new TOML config?
16:49:51 <pbrobinson> a lot of the Edge work that will be useful is just landing upstream now
16:50:14 <nirik> yeah. 'blueprints' I guess?
16:50:27 <nirik> huh, ImageBuilder came out of weldr... interesting.
16:50:54 <pbrobinson> nirik: some bits of IB come out of weldr, others do not
16:51:07 <nirik> ok
16:52:11 <nirik> So, next on the topics is the council ticket thing... but I think we should just drop that now.
16:52:28 <pbrobinson> what's the council ticket thing?
16:52:34 <nirik> Additionally, not sure the format of these meetings is useful, happy to adjust, ideas welcome. ;)
16:52:49 <nirik> #topic council issue #380 - pinephone pro for developers
16:52:49 <nirik> https://pagure.io/Fedora-Council/tickets/issue/380
16:52:52 <nirik> that ^
16:53:33 <be[m]> I haven't read that whole thread. What are the open questions/issues from that?
16:54:04 <pbrobinson> I suspect that can be closed
16:54:21 <nirik> be[m]: I'm not sure myself... I guess it was being pushed as a edition? but I don't think thats practical in f36... perhaps f37 if stuff gets upstreamed fast/nicely.
16:55:00 <pbrobinson> we're a LONG way from an edition
16:55:11 <be[m]> you mean spins?
16:55:27 <pbrobinson> a regular remix is the first step, spin is the second
16:55:45 <nirik> editions are things like workstation, IoT, server, etc... the top level important things fedora makes.
16:55:48 <be[m]> I think we could have Plasma Mobile and Phosh spins before actually getting it running on a Pinephone (Pro)
16:55:52 <nirik> pbrobinson: totally agreed
16:56:14 <be[m]> It would be neat to have an upstream Fedora Plasma Mobile spin running on a Raspberry Pi for example
16:56:16 <nirik> be[m]: how useful would that be on say a laptop? pretty weird
16:57:15 <torsh[m]> I'd still like to get an ostree (like silverblue) phosh spin going
16:57:16 <pbrobinson> be[m]: it would be easier to make the PPP run it TBH
16:57:47 <nirik> It likely doesn't hurt to line up everything for the spin to check in once we have a kernel/uboot/etc that can boot/use vanilla kernel.
16:57:52 <be[m]> What I mean is we could have all the packaging ready to go in upstream Fedora sans the kernel
16:58:12 <nirik> yeah
16:58:15 <be[m]> then when the kernel patches land in upstream Linux it'll hopefully Just Work
16:58:42 <pbrobinson> I posted patches upstream last night to try and get the full accelerated 3d rendering
16:58:53 <be[m]> awesome, thanks
16:59:00 <nirik> cool!
16:59:07 <pbrobinson> we'll see if they get review/accepted
16:59:09 <torsh[m]> Awesome! :D
16:59:17 <nirik> pbrobinson: any idea where uboot is upstream for it? anything already been submitted?
16:59:27 <be[m]> unfortunately megi has like no interest in upstreaming his work and is letting it fall on others to do that
16:59:30 <pbrobinson> U-Boot for what? PPP?
16:59:42 <nirik> yeah... or do we not need it?
16:59:47 <be[m]> we don't need it
16:59:56 <pbrobinson> be[m]: I disagree
16:59:59 <be[m]> we just need to make a generic UEFI bootable image
17:00:00 * nirik really needs to sit down and learn about all the arm booting weirdness.
17:00:13 <pbrobinson> I was going to work on a patch set given I did the Pinebook Pro support for upstream
17:00:36 <nirik> can you chain uboots?
17:01:04 <nirik> (ie, have uboot on the eMMC boot your fedora one on uSD)
17:01:16 <be[m]> I mean if you want to do the work to get upstream uboot functional on the PPP that would be great. But IMO it's tangential to getting Fedora working because distros shouldn't be touching that
17:01:34 <pbrobinson> nirik: the thing with U-Boot is it's not actually just U-Boot, there's actually 4 firmwares for the rk3399 devices for example
17:02:32 <pbrobinson> there SPL (Secondary program loader) which in turn loads ATF (arm trusted firmware which runs in the TrustZone part of the chip) the PMU (power management unit) and then U-Boot
17:02:42 <pbrobinson> then U-Boot proper
17:03:28 <nirik> fun. ok.
17:03:37 <pbrobinson> in fact I need to get back to trying to get the OpenRISC PMU firmware building for the AllWinner a64 so we can have suspend there for the original PP
17:04:12 <be[m]> Samuel is working on getting Tow Boot working on the original PP now
17:04:17 <nirik> #topic General Discussion / AOB
17:04:17 <be[m]> installed to eMMC boot partition
17:04:34 <pbrobinson> I plan on getting an initial PPP firmware in time for F36
17:04:48 <nirik> I hope my pp's are useful someday... but I am hoping ppp can be a daily driver, but we will see.
17:05:22 <pbrobinson> I think Tow-boot is fine, but there's people that have expressed to me via DM they don't want it and there's scope to support both options as long as Tow-boot supports UEFI
17:05:27 <be[m]> long term I plan to keep my original Pinephone as an emergency backup
17:06:31 <nirik> So, any other general things we wanted to bring up/discuss? I think now it's a matter of: packaging up everything we can into fedora, waiting/helping upstream things, see where we are...
17:07:05 <nirik> someone could start working on SXMO too I guess (no idea how hard it would be to package)
17:07:06 <be[m]> right, the point is... let's generate generic UEFI images
17:07:07 <pbrobinson> so the way I see it is 1) general packaging
17:07:19 <pbrobinson> 2) kernel, which is a LOT better for the PPP
17:07:38 <be[m]> and not mess with building our own uboot build and mucking around with the partition table as the original Pinephone scripts do
17:08:02 <pbrobinson> I need to look at the display there, as well as exactly the WiFi module, but those aside with the work we've already done on rk3399 I think it'll be quick to make usable
17:08:27 <pbrobinson> 3) Images, which we should do once we have ImageBuilder, that's definitely the way forward there
17:08:43 <pbrobinson> 4) bringing it all together into a spin
17:08:56 <be[m]> yep, with the display upstreamed we could have a functional upstream spin
17:09:18 * nirik nods.
17:09:23 <be[m]> then maybe even drop device-specific images and just install a downstream PPP kernel package from a COPR
17:09:28 <be[m]> after installing to the device
17:10:13 <nirik> hopefully we don't need it. ;)
17:10:47 <be[m]> I anticipate we will for a while, at least to experiment with patches that aren't ready for upstreaming
17:11:19 <pbrobinson> is there a reason for a device specific image now?
17:11:21 <nirik> well, it would be up to the user anyhow, so sure.
17:11:41 <be[m]> yeah, the upstream kernel has no display driver so it's useless
17:11:41 <nirik> I'd personally prefer a single image that allowed you to switch (of course we need to have a default)
17:11:50 <pbrobinson> patches for one device shouldn't affect the other, that should still be possible with a single image
17:12:15 <nirik> oh, sorry, I am talking about userspace, you all are talking about kernels...
17:12:25 <pbrobinson> I'm talking about it all
17:12:28 <be[m]> if the Fedora kernel maintainers are okay with putting some small patches in the normal Fedora kernel for the PPP that would be cool
17:12:33 <be[m]> I wasn't assuming they would be
17:12:47 <pbrobinson> be[m]: what small patches
17:13:17 <pbrobinson> but even with a remix with a kernel with extra patches you should still be able to do it to support both devices
17:13:21 <nirik> pbrobinson: so, you would prefer a single 'fedora-mobile' image?
17:13:27 <be[m]> nothing specifically, just saying that I doubt everything for the PPP will be upstream in the near future
17:13:48 <pbrobinson> I also have a Popcorn PocketPC I'm planning on adding support for and I expect one image for all 3
17:13:55 <be[m]> I think we should have separate Plasma Mobile and Phosh images just like we have GNOME and KDE images
17:14:47 <be[m]> I'll look into ImageBuilder, see if I can get it to build an ARM64 UEFI image on my laptop
17:14:48 <nirik> we can burn that bridge when we come to it I guess. :)
17:14:54 <be[m]> yeah
17:15:05 <pbrobinson> we should, even with a remix, be able to produce say one phosh iamge to support a whole bunch of devices
17:15:35 * nirik nods.
17:15:46 <nirik> ok, anything else or should we wrap things up?
17:15:51 * nirik has another meeting in 15m
17:15:54 <pbrobinson> nothing from me
17:16:03 <be[m]> likewise
17:16:27 <nirik> ok, many thanks everyone! Lets hope for fast upstreaming and starts of images. ;)
17:16:31 <nirik> #endmeeting