Project

General

Profile

Freedom issue #2107

nextcloud-client depends on qt5-webengine

theova - about 1 year ago - . Updated 13 days ago.

Status:
forwarded upstream
Priority:
freedom issue
Assignee:
% Done:

0%


Description

nextcloud-client depends on qt5-webengine:

$ pacman -Si nextcloud-client | grep -E 'Repository|Depends'
Repository      : community
Depends On      : openssl  sqlite  qtkeychain  qt5-svg  qt5-webengine  xdg-utils

Since the webinterface shoudt not be needed necessarely and the origin owncloud-client hasn't it as a dependencie, I think, it should be possible to run it without qt5-webengine.

Thanks a lot!


Files

auth.patch (7.48 KB) auth.patch theova, 2019-04-27 10:37 AM
PKGBUILD (1.55 KB) PKGBUILD PKGBUILD (v2.5.3 - fixed arch) theova, 2019-08-01 10:50 AM
v2.6.2.zip (5.55 KB) v2.6.2.zip theova, 2019-11-17 02:00 PM

Related issues

Related to Packages - Freedom issue #1167: [chromium][qt5-webengine][electron] QTWebgine/Electron embeds "entire Chromium platform"confirmed

Actions
Related to Packages - Packaging request #1115: [nextcloud-client] add package to PCRnot-a-bug

Actions

History

#1

Updated by theova about 1 year ago

The daily image doesn't use qt5-webengine. An example of a pkgbuild can be seen in the AUR . It would be cool to have this package in the official repository.

#2

Updated by bill-auger about 1 year ago

"appimage" in the package name indicates that as a blob package with qt5-webengine baked in - i.e. not built from source code - i.e. not fit for parabola

i could be wrong about that? - but it is indeed the latest casualty of the chromium->qt5-webengine->electron deluge

#3

Updated by bill-auger about 1 year ago

  • Related to Freedom issue #1167: [chromium][qt5-webengine][electron] QTWebgine/Electron embeds "entire Chromium platform" added
#4

Updated by theova about 1 year ago

bill-auger wrote:

"appimage" in the package name indicates that as a blob package with qt5-webengine baked in - i.e. not built from source code - i.e. not fit for parabola

I didn't know this, thanks.

I contacted the developers of nextloud-client. See https://github.com/nextcloud/desktop/issues/932.

#5

Updated by bill-auger about 1 year ago

i would not expect that github issue to be convincing - this is not a new issue - the qt5-webengine dev team have already been confronted with this issue and they do not believe it is true

also, it is not correct to say that qt5-webengine is definitively considered non-free - it is considered non-free only because it has never been definitively shown to be free

also the link to the FSF is not going to be convincing either - if you really wanted to show them something relevant, this would be a better link to offer

https://lists.gnu.org/archive/html/directory-discuss/2017-11/msg00003.html

IIRC a qt5-webengine dev posted to that thread saying they were willing to fix any freedom issues that can be shown conclusively, if chromium does not address them first - that is the best you could ask of any upstream

lastly, i can say that any problem with qt5-webengine is in what it inherits from chromium - if there is any work to be done verifying or liberating qt5-webengine or electron, the upstream chromium would be the ideal place to do that work - in time, the changes would propagate to the others

#6

Updated by bill-auger 10 months ago

  • Status changed from open to confirmed
#7

Updated by theova 8 months ago

There is a patch to build nextcloud-desktop without qt5-webengine. I can't estimate, if there are any security issues, so it would be good, if somebody could have a look at it.

You can find the patch and the modified (Arch-)PKGBUILD in the attachment.

#8

Updated by bill-auger 8 months ago

  • Priority changed from bug to freedom issue

it looks that people are taking the patch favorably upstream - maybe we should just wait a bit and see if they accept it

#9

Updated by bill-auger 7 months ago

#10

Updated by theova 5 months ago

  • File PKGBUILD added

Here is the updated PKGBUILD for Version 2.5.3.

#11

Updated by freemor 5 months ago

Theova nice work on the updated PKGBUILD. I'm looking at it now. First issue
this is definitely NOT an "arch=(any)" package. It'll build fine that way and
even install on other ARCHs that way but if you try to execute it on an i686
machine you'll be met with an "Can not execute binary file: Exec format error".
This is something you see in AUR packaged a lot and they generally get away
with it due to Archlinux only supporting x86_64. So no biggie but something to
be watching for in the future. Parabola can and does have "any" packages but
these are generally things written in languages like python, perl, bash, or
something like java that is machine independent as it has it's own JVM to
abstract away the actual metal.

Keep up the good work. I'll keep getting to them as I am able. Not sure how
deeply I can test nextcloud client as I do not use nextcloud.

#12

Updated by theova 5 months ago

Thanks for the feedback.
So I have replaced "arch=(any)" with

arch=(x86_64)
arch+=('i686' 'armv7h')
#13

Updated by dario 2 months ago

Version 2.6.0-2 in Community-Testing has a different authentication method that consists in opening the default installed browser. qt5-webengine is still reported as a needed dependency, but maybe it is not really needed.

#14

Updated by sseneca 2 months ago

I've been running the Nextcloud client with the above PKGBUILD for about 2 months now without any issues whatsoever.

#15

Updated by bill-auger 2 months ago

  • Description updated (diff)

sseneca -

to be clear, you used the PKGBUILD uploaded on 2019-08-01 06:50 AM ?

there are multiple attached now, i would like to delete the others

#16

Updated by sseneca 2 months ago

bill-auger wrote:

sseneca -

to be clear, you used the PKGBUILD uploaded on 2019-08-01 06:50 AM ?

there are multiple attached now, i would like to delete the others

Yes, I've been using the PKGBUILD uploaded on 2019-08-01, along with the auth.patch from 2019-04-27.

#17

Updated by bill-auger 2 months ago

  • File deleted (PKGBUILD)
#18

Updated by bill-auger 2 months ago

  • File deleted (PKGBUILD)
#19

Updated by theova 28 days ago

Here is the updated PKGBUILD vor 2.6.1 and the necessary patches. Credits for the updated patch goes to Cogitri.

The old PKGBUILD and auth.patch are no longer needed...

#20

Updated by bill-auger 28 days ago

just for the sake of documentation, does anyone know what functionality is missing from this program in the absence of webengine? - is it only used for login?

#21

Updated by bill-auger 27 days ago

  • Assignee set to bill-auger

'nextcloud-client' v2.6.1 for x86_64 and armv7h are in [libre] now - i686 is being pesky - i did not test it out fully; but it launches - please do try it out in real usage, and let us know if there are any problems with it, and we can close this ticket

#22

Updated by theova 27 days ago

Cool! I can't see 'nextcloud-client' in the abslibre yet. And the parabola package website says "Path not found" as well. Probably I just have to wait...

bill-auger wrote:

just for the sake of documentation, does anyone know what functionality is missing from this program in the absence of webengine? - is it only used for login?

AFAIK it is only used for login. The login method is changed to "HTTP Basic Auth" which is the default fallback method.

#23

Updated by bill-auger 27 days ago

i did not upload it to abslibre yet - the package will take an
hour or a few to propagate to the mirrors

i can add your name and email as "contributor" if you like

#24

Updated by bill-auger 27 days ago

i686 still not building

....
 |  [100%] Built target nextcloud
 |  Scanning dependencies of target doc-man
 |  Traceback (most recent call last):
 |    File "/usr/bin/sphinx-build", line 6, in <module>
 |      from pkg_resources import load_entry_point
 |    File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 84, in <module>
 |      __import__('packaging.requirements')
 |    File "/usr/lib/python3.7/site-packages/packaging/requirements.py", line 9, in <module>
 |      from pyparsing import stringStart, stringEnd, originalTextFor, ParseException
 |  ModuleNotFoundError: No module named 'pyparsing'
 |  make[3]: *** [man/CMakeFiles/doc-man.dir/build.make:57: man/CMakeFiles/doc-man] Error 1
 |  make[2]: *** [CMakeFiles/Makefile2:1315: man/CMakeFiles/doc-man.dir/all] Error 2
 |  make[1]: *** [CMakeFiles/Makefile2:1322: man/CMakeFiles/doc-man.dir/rule] Error 2
 |  make: *** [Makefile:691: doc-man] Error 2

#25

Updated by theova 26 days ago

bill-auger wrote:

please do try it out in real usage, and let us know if there are any problems with it, and we can close this ticket

I don't see any problems :-) For me it works as expected.

bill-auger wrote:

i can add your name and email as "contributor" if you like

Yes, please add me as "Theo von Arx <>"

#26

Updated by bill-auger 13 days ago

  • Status changed from confirmed to forwarded upstream

the problem with i686 is with the arch32 'python-parsing' package

https://bugs.archlinux32.org/index.php?do=details&task_id=93

Also available in: Atom PDF