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.

"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

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.

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

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.

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.

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

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

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?

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

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

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

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

Yes, please add me as "Theo von Arx <theova@member.fsf.org>"

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