[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bringing Mobian closer to Debian



Hi Arnaud,
On Tue, Sep 07, 2021 at 07:00:21PM +0200, Arnaud Ferraris wrote:
> Hi Guido,
> 
> Le 15/08/2021 à 17:10, Guido Günther a écrit :
> >> 2. kernel and bootloader packages including out-of-tree patches
> > 
> > These sound tricky to carry in Debian especially due to kernel security support.
> 
> Agreed, I believe these should stay in Mobian until everything gets
> upstreamed (which is why we would be forced to put at least the
> metapackages in contrib for the time being).
> 
> >> 3. non-free binary firmwares
> > 
> > I hope we can upload these to non-free. Depending on the driver status
> > we can even fold them into firmare-linux-{non,}free upstream.
> 
> As I wrote in my answer to Paul, I'm not sure this is feasible due to a
> lack of legal information on that matter. Still something to
> investigate, though.

Could something similar to fw-cutter¹ help so users can extract it
from existing images so avoid distribution problems?

> 
> >> 4. Mobian base metapackages (meta-mobian) and customizations
> >>    (mobian-tweaks) [4]
> > 
> > I can imagine a meta package for mobian that pulls in "all you need" for
> > a specific device but the reset could live in mobile-tweaks…
> 
> That's the current role of `<device>-support` (metapackage) and
> `mobian-<device>-tweaks`, so you're suggesting we keep the
> `<device>-support` packages and merge all `mobian-*-tweaks` into
> `mobile-tweaks`, am I understanding right?

I think merging mobian-*-tweaks enhancements into the mobile-tweaks
source package would be a great to help Debian to support these devices
better and help lowering the Debian <-> Mobian delta. We have device
specific udev rules, gesttings, etc in there.

It will get hairy if get different device specific requirements for the
mobile environment that runs on top but i hope we can avoid
this. (e.g. phosh specific setting are in phosh-mobile-tweaks but
they're not meant to be device specific).

Regarding '<device>-support': From looking at the package it seems they
add 3 things

1. device specific kernel
2. device specific firmware
3. device specific <device>-tweaks package

Instead of using another layer of packages We could handle that via the
installer since it's a one time thing when either installing the device
with d-i or or when creating an image to be flashed to the device (via
e.g. debos, fai). d-i has support for figuring out firmware based on
modalias and maybe we need to extend this with DT support or come up
with a tool that can be used for other image creation methods as well
and then reused by d-i? 

> 
> >> 5. device-specific metapackages ($device-support) and customizations
> >>    (mobian-$device-tweaks) [5]
> > 
> > …that's basically why we came up with mobile-tweaks-common and
> > <device>-tweaks. Could you imagine anything that woukdn't fit either
> > into this package or into the corresponding upstream repo (like e.g. ucm
> > profiles)?
> 
> It all depends on our policy for `mobile-tweaks`: for example, we agreed
> not to ship the ModemManager polkit customizations as part of
> `mobile-tweaks`, so we (Mobian) have to carry it in some `mobian-tweaks`
> package for now.

I think the ModemManager polkit rule is a good example of where we
should reach consensus and then NMU (the package was NMUed since quite a
while) rather than leaving it "broken" (as in not usable for the phone
case). I think the "policy" should be: fix it in the package itself and
if we can't (e.g. we'd break another use case) then move to
mobile-tweaks.

> > Looking at that bug and the examples mentioned there these are mostly
> > things where we don't have a solution in place in Debian e.g. MM polkit
> > rule. I think we should push towards solving this within Debian wherever
> > possible and then see what's left after a couple of months. First step
> > could be filing the bugs and using a user tag so we can keep an
> > overview. Should we try that?
> 
> That makes sense, yes.
> 
> Maybe I could start by creating MRs on mobile-tweaks for importing our
> device-specific tweaks, so we can more easily identify and discuss the
> problematic bits on a case-by-case basis? We'll see how it goes from
> there, that might give us a few leads regarding future actions.

Sounds great to me!
 -- Guido

> 
> Cheers,
> Arnaud
> 
> > Cheers,
> >  -- Guido
> > 
> >>
> >> FYI, this question was raised when I filed an ITP for mobian-tweaks[7],
> >> although my answer would probably be different today.
> >>
> >> ==========
> >>
> >> So basically, here's the global picture, and we'd very much like to
> >> read your thoughts on that matter.
> >>
> >> Thanks,
> >> The Mobian team
> >>
> >> ---
> >>
> >> [1] https://mobian-project.org/
> >> [2] https://packages.mobian-project.org/
> >> [3] https://wiki.debian.org/Teams/DebianOnMobile
> >> [4] https://salsa.debian.org/Mobian-team/
> >> [5] https://gitlab.com/mobian1/devices
> >> [6] https://salsa.debian.org/DebianOnMobile-team/mobile-tweaks
> >> [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974422#10
> > 
> > 
> > 
> > 
> > 
> 

1) https://manpages.debian.org/bullseye/b43-fwcutter/b43-fwcutter.1.en.html


Reply to: