GNU bug report logs - #56664
[PATCH] gnu: Add qtscrcpy.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56664 in the body.
You can then email your comments to 56664 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: phodina <phodina <at> protonmail.com>
To: Guix Patches <guix-patches <at> gnu.org>
Subject: [PATCH] gnu: Add qtscrcpy.
Date: Wed, 20 Jul 2022 13:20:23 +0000

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

[0001-gnu-Add-qtscrcpy.patch (text/x-patch, attachment)]

Message #8 received at 56664 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: phodina <phodina <at> protonmail.com>, 56664 <at> debbugs.gnu.org
Subject: Re: [bug#56664] [PATCH] gnu: Add qtscrcpy.
Date: Wed, 20 Jul 2022 15:48:28 +0200

[Message part 1 (text/plain, inline)]

On 20-07-2022 15:20, phodina via Guix-patches via wrote:
> 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?

>  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?

> NOT require

We are not restricted to plain text in descriptions, you can use Texinfo 
markup like @emph.

Greetings,
Maxime.

[Message part 2 (text/html, inline)]

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #11 received at 56664 <at> debbugs.gnu.org (full text, mbox):

From: phodina <phodina <at> protonmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 56664 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: [bug#56664] [PATCH] gnu: Add qtscrcpy.
Date: Wed, 20 Jul 2022 15:03:50 +0000

[Message part 1 (text/plain, inline)]

Hi Maxime,

> - 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?

> 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]?

> 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.

> 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?

> Also, why are tests disabled?

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

> We are not restricted to plain text in descriptions, you can use Texinfo markup like @emph.

Thanks, will use more the markup :-)

[1] https://framagit.org/tyreunom/guix-android
[2] https://github.com/barry-ran/QtScrcpy/tree/v2.0.1/server

----
Petr

[Message part 2 (text/html, inline)]

Message #14 received at 56664 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: phodina <phodina <at> protonmail.com>
Cc: 56664 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: [bug#56664] [PATCH] gnu: Add qtscrcpy.
Date: Wed, 20 Jul 2022 17:10:34 +0200

[Message part 1 (text/plain, inline)]

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.

Greetings,
Maxime.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #17 received at 56664 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: phodina <phodina <at> protonmail.com>
Cc: 56664 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: [bug#56664] [PATCH] gnu: Add qtscrcpy.
Date: Wed, 20 Jul 2022 17:17:39 +0200

[Message part 1 (text/plain, inline)]

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.

Greetings,
Maxime.

[Message part 2 (text/html, inline)]

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #20 received at 56664 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: phodina <phodina <at> protonmail.com>
Cc: 56664 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: [bug#56664] [PATCH] gnu: Add qtscrcpy.
Date: Wed, 20 Jul 2022 17:18:35 +0200

[Message part 1 (text/plain, inline)]

On 20-07-2022 17:10, Maxime Devos wrote:
> 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.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #23 received at 56664 <at> debbugs.gnu.org (full text, mbox):

From: phodina <phodina <at> protonmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 56664 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: [bug#56664] [PATCH] gnu: Add qtscrcpy.
Date: Wed, 20 Jul 2022 15:32:26 +0000

[Message part 1 (text/plain, inline)]

> 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

[Message part 2 (text/html, inline)]

Message #28 received at 56664-done <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: 56664-done <at> debbugs.gnu.org
Subject: Close
Date: Sat, 21 Jun 2025 18:02:16 +0200

I concur with the analysis about prebuilt files, which makes this
package not acceptable to Guix. As the issue seems not actionable,
I am closing it.

Andreas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.