Hi again, On 08/31/2017 12:17 AM, Christoph Biedl wrote: > Christoph Biedl wrote... > >> * The build failure on i386 (also seen on armhf) and probably >> all other 32bit archs needs to be fixed. > [...] This is fixed upstream now: https://github.com/dino/dino/commit/dc26841b9e
I updated my package for this new snapshot, and it seems to build (32-bit too) and run (tested 64-bit) ok. There is also this: https://build.opensuse.org/package/show/network:messaging:xmpp:dino/dino (https://download.opensuse.org/repositories/network:/messaging:/xmpp:/dino/Debian_9.0/) Upstream seems to be involved with this package, but: - They reuse the "dino" name (which is still used in oldstable - can it be reused already? should it be reused?) - There is a dev package, but no lib package; that is probably a bad idea - A dev package requires IMHO a commitment to stable ABI (and SONAME bumps), and given that there isn't even a release yet I wouldn't rely on that. - The platform independent files are not in a separate package. - The magic "_service"-link to automatically update on each commit seems to package git-submodules directly (so they don't need the symlink hack I had to use in debian/rules) Imho unresolved: a) libsignal-protocol-c should be packaged separately (#840366) b) I didn't check the source for any other inlined (re)sources which might already be packaged separately, and I didn't check the licenses either. Did someone else check? c) There are 3 shared libraries provided by the package, which the plugins link against, so they can't be linked statically. But they are in the standard shared library directory. I don't think upstream is ready to provide a stable API yet, so a separate dev and lib package imho doesn't make sense (otherwise you'd have to so-bump on every release). What is the correct way to package these shared libraries in the meantime? Append the package version to the binary basename? One day dev and lib package could be provided, is it possible to split the package then without so-bump with the current names? I went with renaming the "qlite" and "xmpp-vala" shared libraries to "dino-qlite" and "dino-xmpp-vala" for now, so they at least live in their own namespace (and this might be a good idea even in the long run - maybe ask upstream to do the same?). d) lintian: W: dino-xmpp-client: desktop-mime-but-no-exec-code usr/share/applications/dino.desktop e) "dino" vs "dino-xmpp-client"? cheers, Stefan
