[Pkg-owncloud-maintainers] ownCloud client packages are pretty outdated

[Pierre-Elliott Bécue]

Fabian Müller <fmueller at owncloud.com> wrote on 05/10/2022 at 01:43:08+0200:

> [[PGP Signed Part:No public key for 06DF746EADCA2A93 created at 2022-10-05T01:43:08+0200 using EDDSA]]
> Hi Pierre-Elliot,
>
> On 29.09.22 00:43, Pierre-Elliott Bécue wrote:
>
>> I've just uploaded owncloud-client v 2.11.0.8354 to unstable after
>> testing it locally on my workstation. Hopefully if bugs are spotted
>> people will yell at me and I'll be able to fix the packaging fastly. I
>> know 2.11.1.8438 is available, but the usual GPG signature you provide
>> along with the tarball is missing, and I decided not to package it right
>> now.
>> If you wish, have the GPG sig added and I'll do another upload.
>
> Great progress!
>
> Sorry for the inconvenience re. 2.11, apparently the upload on our
> server did not work as intended for the "latest" directory [1], I
> copied the file over from the "2.11" directory [2]. Thanks for letting
> us know by the way, this had been broken for a while.
>
> Please beware that 2.11.1 fixes an annoying crash that affected all
> platforms which we introduced in 2.11.0. See [3]. 2.11.0 should
> probably not be shipped in stable or testing. Other than the small
> change, the versions are pretty much the same, so it should be
> relatively easy to update the package.

I do intend to update to 2.11.1, don't worry! :)

That being said, do you intend to do some LTS support on 2.11.X?

>> Side questions, which are not urgent, but at least could benefit from your
>> knowledge:
>> 1. Lintian raises one error I think I did not see on earlier
>> versions of
>> owncloud-client:
>> E: dolphin-owncloud: custom-library-search-path RUNPATH
>> /usr/lib/x86_64-linux-gnu/owncloud
>> [usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/overlayicon/ownclouddolphinoverlayplugin.so]
>> N:
>> N:   The binary or shared library sets RPATH or RUNPATH. This overrides the
>> N:   normal library search path, possibly interfering with local policy and
>> N:   causing problems for multilib, among other issues.
>> N:
>> N:   The only time a binary or shared library in a Debian package should set
>> N:   RPATH or RUNPATH is if it is linked to private shared libraries in the
>> N:   same package. In that case, place those private shared libraries in
>> N:   /usr/lib/*package*. Libraries used by binaries in other packages should be
>> N:   placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which
>> N:   case RPATH/RUNPATH is unnecessary.
>> N:
>> N:   To fix this problem, look for link lines like: gcc test.o -o test
>> N:   -Wl,--rpath,/usr/local/lib or gcc test.o -o test -R/usr/local/lib and
>> N:   remove the -Wl,--rpath or -R argument. You can also use the chrpath
>> N:   utility to remove the RPATH.
>> N:
>> N:   Please refer to https://wiki.debian.org/RpathIssue for details.
>> N:
>> N:   Visibility: error
>> N:   Show-Always: no
>> N:   Check: binaries/rpath
>> N:   Renamed from: binary-or-shlib-defines-rpath
>> Is this new, that you use RPATH/RUNPATH or has it always been the
>> case?
>
> Took me a moment to figure out why this occurs in your builds, since
> our builds don't use the directory and also don't set an rpath
> apparently. The rpath is added by maintainer patch 0009, which changes
> the installation path of some part of the Dolphin integration. If it
> wasn't set, the library couldn't be found. I don't think it's a good
> idea to remove the patch, I suppose the authors knew what they were
> doing. See [4].

Indeed, I fell on it after asking you that, browsing the patched code,
and seeing that the thing is not in the original one. I think I'll drop
the lintian error for now.

>> 2. How about the documentation? Will I be able to include it again in a
>> nearby future?
>
> Quoting myself from June:
>
>> Maybe you can elaborate on what kind of format you'd need and/or
>> prefer? I'll happily discuss ideas with the team. We already thought
>> about providing specialized tarballs for distro packaging purposes. We
>> could for instance just add the client docs source (or maybe compiled
>> HTML) to them.
>
> I need some information before I can try to make it usable for you. Do
> you need a single file rendering of some kind? Is the Antora source
> code (AsciiDoc), maybe distributed as an archive, good enough?

I'd probably be happy with txt/rst. The good thing with rst is that I
can build some easy HTML doc I guess, but it's not mandatory.

> As said:
>
>> We're interested in making your life a little bit easier, so please
>> let us know how we can help sort this out. We know distros like Debian
>> have special requirements and rules, and you're the ones who know them
>> best.

Thanks a lot for your help with this update! :)
-- 
PEB