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

[Pierre-Elliott Bécue]

Hello Fabian,

Fabian Müller <fmueller at owncloud.com> wrote on 07/07/2022 at 12:49:47+0200:

> [[PGP Signed Part:No public key for 06DF746EADCA2A93 created at 2022-07-07T12:49:47+0200 using EDDSA]]
> On 26.06.22 22:12, Pierre-Elliott Bécue wrote:
>
>> In the meantime, I have another issue, it seems that in the current
>> build process of the package, the translations that previously were
>> built in /usr/share/owncloud-client/i18n are no longer built.
>> Did your translation system change?
>
> Sorry for the delay. Indeed this has changed since. We now compile all
> translations into the binaries using Qt's resource system. This has 
> turned out to be a lot more reliable. See [1-3]. I guess you can
> remove the l10n package entirely.
>
> [1] https://github.com/owncloud/client/issues/8822
> [2] https://github.com/owncloud/client/pull/8838
> [3] https://github.com/owncloud/client/issues/8839

Sorry, too, my summer was a bit full and I had some administrative stuff
to care about, so this package fell off my radar.

Thanks for the clarification about l10n.

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.

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?

2. How about the documentation? Will I be able to include it again in a
nearby future?

Cheers!
-- 
PEB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 853 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-owncloud-maintainers/attachments/20220929/67505981/attachment.sig>