Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Fri, Jun 22, 2018 at 06:04:14PM +0100, Ben Hutchings wrote: > I needed to make some small changes to build them as modules. The next > upload using Linux 4.17 should include ashmem_linux and binder_linux > modules for amd64, arm64 and armhf. I looked at it, and it seemed like making the mainline version of ashmem build as a module would indeed take only small changes. I did not have the time to actually do it, and it sounds like Ben just has done so. The driver is in staging/ thus perhaps you could push the patch gregkh's way? This would help people who use vanilla kernels. Binder is already module-capable. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target.
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Sat, Jun 23, 2018 at 1:04 AM Ben Hutchings wrote: > I needed to make some small changes to build them as modules. The next > upload using Linux 4.17 should include ashmem_linux and binder_linux > modules for amd64, arm64 and armhf. > Thanks for your time! -- Best regards, Shengjing Zhu
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Wed, 2018-06-20 at 16:04 +0800, Shengjing Zhu wrote: > Hi Ben, > > On Thu, Jun 14, 2018 at 10:46 AM Shengjing Zhu wrote: > > > > On Thu, Jun 14, 2018 at 01:09:39AM +0100, Ben Hutchings wrote: > > > I agree, I don't think it makes much sense to build these OOT if > > > they > > > can be built in-tree. > > > > Here goes the bug #901492 (linux: Please enable Android ashmem and > > binder module) > > Is there any update about this? > It's it acceptable to enable the in-tree version, as built-in module? > Or it would be better to continue this dkms package as they can't be > built as modules? I needed to make some small changes to build them as modules. The next upload using Linux 4.17 should include ashmem_linux and binder_linux modules for amd64, arm64 and armhf. Ben. > > > > > The in-tree version of ashmem *cannot* be built as a module, > > > though, > > > which we would probably want to change. > > -- Ben Hutchings To err is human; to really foul things up requires a computer. signature.asc Description: This is a digitally signed message part
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
Hi Ben, On Thu, Jun 14, 2018 at 10:46 AM Shengjing Zhu wrote: > > On Thu, Jun 14, 2018 at 01:09:39AM +0100, Ben Hutchings wrote: > > I agree, I don't think it makes much sense to build these OOT if they > > can be built in-tree. > > Here goes the bug #901492 (linux: Please enable Android ashmem and binder > module) Is there any update about this? It's it acceptable to enable the in-tree version, as built-in module? Or it would be better to continue this dkms package as they can't be built as modules? > > > The in-tree version of ashmem *cannot* be built as a module, though, > > which we would probably want to change. > -- Best regards, Shengjing Zhu
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Thu, Jun 14, 2018 at 01:09:39AM +0100, Ben Hutchings wrote: > On Wed, 2018-06-13 at 13:23 +0200, Adam Borowski wrote: > > Hi Ben! > > Could you please chime in to bug #901134 (RFS: anbox-modules)? > > > > This package wants to ship redundant copies of two modules (ashmem and > > binder) that are already in mainline since a long time ago. This strikes me > > as thoroughly wrong, yet I'm very ignorant about packaged kernels, thus I > > can't offer good advice. > > I agree, I don't think it makes much sense to build these OOT if they > can be built in-tree. > Here goes the bug #901492 (linux: Please enable Android ashmem and binder module) > The in-tree version of ashmem *cannot* be built as a module, though, > which we would probably want to change. > Don't have knowledge about this, but I'd like to see it built as module. signature.asc Description: PGP signature
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Thu, Jun 14, 2018 at 8:09 AM Ben Hutchings wrote: [...] > I do wonder what the value of enabling these as in-tree modules would > be. I don't think we package the many Android userspace services and > libraries that would be needed to run Android apps. So how would these > modules be useful? Is the idea to support running an Android system in > a container? Yes, there's no value for most people to have these two modules. It's only used when you want to run Android in a container(most probably you want to run some applications/games which only have mobile version but no free alternative on Debian). Anbox[1] is the approach to do this. If you want to test, you can have a look at my other RFS(#901137). Also noted, anbox will be in contrib area, since we don't have Android image(rootfs) in main. [1] https://github.com/anbox/anbox -- Best regards, Shengjing Zhu
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Wed, 2018-06-13 at 13:23 +0200, Adam Borowski wrote: > Hi Ben! > Could you please chime in to bug #901134 (RFS: anbox-modules)? > > This package wants to ship redundant copies of two modules (ashmem and > binder) that are already in mainline since a long time ago. This strikes me > as thoroughly wrong, yet I'm very ignorant about packaged kernels, thus I > can't offer good advice. I agree, I don't think it makes much sense to build these OOT if they can be built in-tree. The in-tree version of ashmem *cannot* be built as a module, though, which we would probably want to change. [...] > Indeed, these two modules are not built within Debian kernels. They depend > on CONFIG_ANDROID, which doesn't look like it does anything anymore except > allowing to enable these two modules. I have bad memories of Android > kernels doing some very naughty things (magic hard-coded uids/gids, etc), > but I don't know if that was related to CONFIG_ANDROID or not. Even if it > was in the past, it seems that in mainline that setting is safe to enable. > > But, all of this lies in Ben's kingdom, of which I'm not knowledgeable > enough. Thus, some advice would be nice. I do wonder what the value of enabling these as in-tree modules would be. I don't think we package the many Android userspace services and libraries that would be needed to run Android apps. So how would these modules be useful? Is the idea to support running an Android system in a container? Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
Hi Ben! Could you please chime in to bug #901134 (RFS: anbox-modules)? This package wants to ship redundant copies of two modules (ashmem and binder) that are already in mainline since a long time ago. This strikes me as thoroughly wrong, yet I'm very ignorant about packaged kernels, thus I can't offer good advice. On Wed, Jun 13, 2018 at 10:37:42AM +0800, Shengjing Zhu wrote: > On Wed, Jun 13, 2018 at 02:30:18AM +0200, Adam Borowski wrote: > > > anbox-modules-dkms - Android kernel driver (binder, ashmem) in DKMS > > > format > > > > Could you please explain (here and/or in the package's description) reasons > > why an user would prefer this version of the modules over what's in mainline > > kernel trees? > > > > This upstream repo in out-of-tree format can be built against various > kernel versions. > > I think upstream creates this repo because many distributions(including > most Debian based) don't enable these modules in their kernel. > > Since this repo already exists, then packaging it is more convenient to > enable these modules in kernel(and waiting other Debian derivatives to > sync up, not sure if they just sync with Debian or have own kernel > config). Indeed, these two modules are not built within Debian kernels. They depend on CONFIG_ANDROID, which doesn't look like it does anything anymore except allowing to enable these two modules. I have bad memories of Android kernels doing some very naughty things (magic hard-coded uids/gids, etc), but I don't know if that was related to CONFIG_ANDROID or not. Even if it was in the past, it seems that in mainline that setting is safe to enable. But, all of this lies in Ben's kingdom, of which I'm not knowledgeable enough. Thus, some advice would be nice. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄ (funeral doom metal).
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Wed, Jun 13, 2018 at 02:30:18AM +0200, Adam Borowski wrote: > > anbox-modules-dkms - Android kernel driver (binder, ashmem) in DKMS > > format > > Could you please explain (here and/or in the package's description) reasons > why an user would prefer this version of the modules over what's in mainline > kernel trees? > This upstream repo in out-of-tree format can be built against various kernel versions. I think upstream creates this repo because many distributions(including most Debian based) don't enable these modules in their kernel. Since this repo already exists, then packaging it is more convenient to enable these modules in kernel(and waiting other Debian derivatives to sync up, not sure if they just sync with Debian or have own kernel config). I don't have good sentence for package description. Suggestions are welcome. > Also, you have GPL-3 scripts managing GPL-2 modules, this is borderline and > I'm not quite sure of which side of the border. > the debian/ directory is split from previous anbox package, which is in GPL-3. Since all things in debian/ dir are written by myself, it's easy to change the license. But I don't think it would be problem. Just to clarify, there's no d/patches file, so no GPL-3 code is patched to GPL-2 code. -- Regards, Shengjing Zhu signature.asc Description: PGP signature
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Sat, Jun 09, 2018 at 05:49:58PM +0800, Shengjing Zhu wrote: > * Package name: anbox-modules >Version : 0.0~git20180608-1 >Upstream Author : Simon Fels > * URL : https://github.com/anbox/anbox-modules/ > * License : GPL-2 >Section : kernel > > It builds those binary packages: > > anbox-modules-dkms - Android kernel driver (binder, ashmem) in DKMS format Could you please explain (here and/or in the package's description) reasons why an user would prefer this version of the modules over what's in mainline kernel trees? Also, you have GPL-3 scripts managing GPL-2 modules, this is borderline and I'm not quite sure of which side of the border. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄ (funeral doom metal).
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: Chris Lamb Dear mentors, I am looking for a sponsor for my package "anbox-modules" * Package name: anbox-modules Version : 0.0~git20180608-1 Upstream Author : Simon Fels * URL : https://github.com/anbox/anbox-modules/ * License : GPL-2 Section : kernel It builds those binary packages: anbox-modules-dkms - Android kernel driver (binder, ashmem) in DKMS format To access further information about this package, please visit the following URL: https://mentors.debian.net/package/anbox-modules Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/anbox-modules/anbox-modules_0.0~git20180608-1.dsc Regards, Shengjing Zhu signature.asc Description: PGP signature
