[PATCH] gnu: Add qtscrcpy.

  • Open
  • quality assurance status badge
Details
2 participants
  • Maxime Devos
  • phodina
Owner
unassigned
Submitted by
phodina
Severity
normal
P
P
phodina wrote on 20 Jul 2022 15:20
(name . Guix Patches)(address . guix-patches@gnu.org)
DXNUqTrJ0MYzJVegrgd4AzdR8xXS7jKuGOGJxWYZfl0q5sJ5AM5GqgSVn-kYTgZP8HyL-RQVjTULOLKNAmXukf9wWbQER42MXPyjlOOWkmw=@protonmail.com
Hi,

this patch adds support for screen mirroring Android phones on the desktops.

There are 2 remarks:

- The Android part scrcpy-server is prebuild due to Guix not supporting gradle and Android builds. Without this the tool does not work.

- I've currently hardcoded the x86 architecture in the install phase. Not sure how to make it architecture agnostic.

----
Petr
Attachment: file
Attachment: 0001-gnu-Add-qtscrcpy.patch
M
M
Maxime Devos wrote on 20 Jul 2022 15:48
acd00d5a-ded1-1a01-3072-7fc09813afed@telenet.be
On 20-07-2022 15:20, phodina via Guix-patches via wrote:
Toggle quote (11 lines)
> Hi,
>
> this patch adds support for screen mirroring Android phones on the
> desktops.
>
> There are 2 remarks:
>
> 1. The Android part scrcpy-server is prebuild due to Guix not
> supporting gradle and Android builds. Without this the tool does
> not work.
>
OK, though then this is a draft patch that's blocked by supporting
gradle and Android; Guix is a build-from-source distro (there are some
bootstrap seeds, but the idea is to reduce them, not enlarge them).
Someone else has been looking into supporting Android (something about a
longsoon-build-system), maybe you can test that, and I don't know if
anyone has been looking at addressing the gradle problems.
Also, from a cursory look, I'm not seeing gradle there and neither am I
seeing Android builds, maybe all that's needed is adding the adb package
(which is packaged in Guix), no gradle or Android support needed, or I
didn't look in the right places?
Toggle quote (2 lines)
>  I've currently hardcoded the x86 architecture in the install phase.
> Not sure how to make it architecture agnostic.
When building from source this is usually automatic, though I don't know
if this applies to Gradle.
Also, why are tests disabled?
Toggle quote (1 lines)
> NOT require
We are not restricted to plain text in descriptions, you can use Texinfo
markup like @emph.
Greetings,
Maxime.
Attachment: file
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
P
P
phodina wrote on 20 Jul 2022 17:03
(name . Maxime Devos)(address . maximedevos@telenet.be)
aFW_3GO_xxcIBIsJ-jSVwWYZkUFtX5Vs4IbtP4XC8FRmFWLSvY6nRbweVFekQdbUFFoyY_LG4RyR-_ObGIiSOONMsFkyF_bnqi7AxQTA2Io=@protonmail.com
Hi Maxime,

Toggle quote (4 lines)
> - The Android part scrcpy-server is prebuild due to Guix not supporting gradle and Android builds. Without this the tool does not work.
>
> OK, though then this is a draft patch that's blocked by supporting gradle and Android; Guix is a build-from-source distro (there are some bootstrap seeds, but the idea is to reduce them, not enlarge them).

I understand that the aim is to reduce the prebuild stuff not vice versa that's why I labeled it here. One solution could be to replace the location by specifying some env variable and the user would supply either the prebuild version from the repo or build it themself e.g. in Docker.

This way the package would not have any prebuild files. Would that be okay?

Toggle quote (2 lines)
> Someone else has been looking into supporting Android (something about a longsoon-build-system), maybe you can test that, and I don't know if anyone has been looking at addressing the gradle problems.

Do you mean the work of Julien Lepiller [1]?

Toggle quote (2 lines)
> Also, from a cursory look, I'm not seeing gradle there and neither am I seeing Android builds, maybe all that's needed is adding the adb package (which is packaged in Guix), no gradle or Android support needed, or I didn't look in the right places?

Android sources are located under the directory server [2]. There's also meson build file but it will still need Android build environment to create the executable out of the java files.

Toggle quote (2 lines)
> I've currently hardcoded the x86 architecture in the install phase. Not sure how to make it architecture agnostic.

Here I'm refering to the CMake which places the output in 'output/x86/...' directory. Unfortunately the CMakeLists.txt does not specify how to install the files so it has to be done manually.

Could you suggest some package which I could use as an example to write Guile code that will make it independent of the machine arch?

Toggle quote (2 lines)
> Also, why are tests disabled?

Haven't found any. Will add note about no test suite.

Toggle quote (2 lines)
> We are not restricted to plain text in descriptions, you can use Texinfo markup like @emph.

Thanks, will use more the markup :-)


----
Petr
Attachment: file
M
M
Maxime Devos wrote on 20 Jul 2022 17:10
(name . phodina)(address . phodina@protonmail.com)
f721cf25-7a55-fafe-fb94-1d3bfbb98342@telenet.be
On 20-07-2022 17:03, phodina wrote:
Toggle quote (2 lines)
> Could you suggest some package which I could use as an example to
> write Guile code that will make it independent of the machine arch?
Maybe look for target-x86-64?, target-aarch64?, etc, and do something
like #$(cond ((target-x86-32?) "x86") ...).
As an example, maybe openssl, though it's not ideal given that it does
string-prefix? and not target-specific subdirectories.
Greetings,
Maxime.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
M
M
Maxime Devos wrote on 20 Jul 2022 17:17
(name . phodina)(address . phodina@protonmail.com)
93ae770e-37f0-b72b-621d-559904f1b0cc@telenet.be
On 20-07-2022 17:03, phodina wrote:
Toggle quote (15 lines)
>
> OK, though then this is a draft patch that's blocked by supporting
> gradle and Android; Guix is a build-from-source distro (there are
> some bootstrap seeds, but the idea is to reduce them, not enlarge
> them).
>
> I understand that the aim is to reduce the prebuild stuff not vice
> versa that's why I labeled it here. One solution could be to replace
> the location by specifying some env variable and the user would supply
> either the prebuild version from the repo or build it themself e.g. in
> Docker.
>
> This way the package would not have any prebuild files. Would that be
> okay?
>
The package would not have prebuild files, but the user will have to
download some prebuild files anyway, so effectively the problem of
prebuild files remains (the user has to trust some random download
location to have an unbackdoored binary, that they can not inspect, and
while they can modify the source code, it's useless because they can't
compile it; Guix cannot exercise freedom 1).
Also, one of the primary tasks of a package manager is to keep track of
dependencies, automatically installing the (non-optional) dependencies,
which seems incompatible with telling a user to grab a dependency from
outside the package manager.
As such, I believe this not to be okay, and that it is required to make
gradle & Android things functional first.
Greetings,
Maxime.
Attachment: file
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
M
M
Maxime Devos wrote on 20 Jul 2022 17:18
(name . phodina)(address . phodina@protonmail.com)
ba9566d1-11cd-3b19-c908-30d3d4a7f2b6@telenet.be
On 20-07-2022 17:10, Maxime Devos wrote:
Toggle quote (10 lines)
> On 20-07-2022 17:03, phodina wrote:
>
>> Could you suggest some package which I could use as an example to
>> write Guile code that will make it independent of the machine arch?
>
> Maybe look for target-x86-64?, target-aarch64?, etc, and do something
> like #$(cond ((target-x86-32?) "x86") ...).
>
> As an example, maybe openssl, though it's not ideal given that it does
> string-prefix? and not target-specific subdirectories.
IIRC, gcrypt-error (or gnupg-error?) does something similar.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
P
P
phodina wrote on 20 Jul 2022 17:32
(name . Maxime Devos)(address . maximedevos@telenet.be)
zAIZC6gmUyiL2hamWObFyXB6AsHdevfFmWIbavhYWjjwTOhJS_LMgfo1AsfcGw-bvklvoyN7G83cWGRrDmRIQs__p-2K_kYZSPKcaQYolkQ=@protonmail.com
Toggle quote (14 lines)
> On 20-07-2022 17:03, phodina wrote:
>
>>> OK, though then this is a draft patch that's blocked by supporting gradle and Android; Guix is a build-from-source distro (there are some bootstrap seeds, but the idea is to reduce them, not enlarge them).
>>
>> I understand that the aim is to reduce the prebuild stuff not vice versa that's why I labeled it here. One solution could be to replace the location by specifying some env variable and the user would supply either the prebuild version from the repo or build it themself e.g. in Docker.
>>
>> This way the package would not have any prebuild files. Would that be okay?
>
> The package would not have prebuild files, but the user will have to download some prebuild files anyway, so effectively the problem of prebuild files remains (the user has to trust some random download location to have an unbackdoored binary, that they can not inspect, and while they can modify the source code, it's useless because they can't compile it; Guix cannot exercise freedom 1).
>
> Also, one of the primary tasks of a package manager is to keep track of dependencies, automatically installing the (non-optional) dependencies, which seems incompatible with telling a user to grab a dependency from outside the package manager.
>
> As such, I believe this not to be okay, and that it is required to make gradle & Android things functional first.

I also don't want to trust unknown sources and prefer to run executables build from sources. That's why I'm interested in Guix.

It's true that the task of the package manager should be to track down dependencies and leaving it to runtime check is reciepe for disaster.

So this package has to be labeled as a draft until Android build system is provided and the server binary can be reproducibly built.

----
Petr
Attachment: file
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 56664@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 56664
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch