Re. subsurface: FTBFS in experimental

Pierre-Yves Chibon pingou at pingoured.fr
Wed Aug 26 07:20:16 PDT 2015


On Wed, Aug 26, 2015 at 06:50:20AM -0700, Dirk Hohndel wrote:
> > I looked quickly over the spec file and I call already tell that the spec file
> > used would not be valid on Fedora, even more fun the source rpm doesn't even
> > build on Fedora.
> 
> Patches welcome. Please help me make this better - I already have a
> contributor helping me with making sure the OpenSUSE packages are
> acceptable to them.

I wonder if OBS can handle building Fedora packages following the Fedora
guidelines, worst case we could use copr: http://copr.fedoraproject.org/
but that would make you rely on two places to distribute RPMs

Note: since F22, copr is nicely integrated with dnf and copr does not suffer
most of the restriction that have the main repos, such as the bundling policy.
So you could build subsurface on copr as you do it in OBS without problem and
users would:

dnf copr enable <user>/subsurface
dnf install subsurface

(for the dnf integration: http://dnf.baseurl.org/2014/03/19/copr-plugin/ )

> > So no, I would not install your binary on my machine but then again, I am maybe
> > just too experienced in this domain, maybe most of our users don't care of these
> > things.
> 
> Pierre, I really appreciate the work that you have done for Subsurface.
> Here's a hypothetical question for you. Assume you bring ten thousand
> divers in a room and you ask them "what do you prefer, making sure that
> the source rpm of your dive log software builds on your Linux distribution
> of choice or that your dive software has the features that are discussed
> in its manual and the user experience matches what is documented in the
> manual and on their web site?". What do you think the answers will be?
> 
> My guess is 90% will say "I don't care, I don't log my dives / only paper
> log books are valid". The remaining 1000 will go with option b. The
> likelihood that there is a single person in that group of ten thousand
> random divers who even KNOWS what source RPM is has gone up lately, but
> the likelihood that there is someone who cares about these inner details
> enough to stop using Subsurface is miniscule.

I realize this and this was the reason behind the later part of my comment :)
 
> > This whole situation is kinda sad to me. I love subsurface and what it allowed
> > me to do. I maintain subsurface and libdivecomputer in Fedora but I guess I
> > won't be able to soon. I could have integrated your patches in libdivecomputer
> > (already compiled as a static library, for subsurface), we could have worked
> > with the libmarble folks to integrate the desired changes, we could have
> > specified an exact version of libgit2 required, but no, I've been asked to just
> > forget the time I invested in this and instead use a binary provided that
> > doesn't even build on my OS.
> 
> ArchLinux still has their own package. I worked with the maintainer and
> it's built using our libs. I'll be more than happy to do the same with
> you. The Debian / Ubuntu situation was especially annoying as they were
> still shipping Subsurface 4.2. Which is why I asked them to drop it.
> You on the other hand have always been extremely good at keeping things
> updated.
> 
> I'll tell you the same thing I'm telling everyone else. If we can find a
> way to create a consistent user experience for our users I'll be more than
> happy to work with you and figure out a solution. So if you would like to
> make sure that Subsurface in Fedora matches what we build for all the
> other OSs, by all means, please work with me. Patches are welcome, I'll be
> happy to integrate necessary changes. But I would like to make sure that
> we build against the versions of libdivecomputer and libssrfmarblewidget
> that we use in the official version and that we use libgit2 0.23 (built
> against libcurl) and the latest libgrantlee - as otherwise cloud storage
> and the new printing system won't work.

The easiest action for me would be that we modify our "forks" to allow to
install them in parallel to the normal ones.
This way, I could package subsurface-libssrfmarblewidget that subsurface would
rely on without having any conflicts or impacting any other packages in Fedora,
same thing for grantlee and the others.

For libdivecomputer, is it just a matter of taking the patches from our git and
pile them up on the top of the 0.4.2 tag?
Do we have a bug referenced on the upstream project for all/most/some of them?
(This way we could track which patches got merged upstream and which didn't at
the next release).

libgit2 in Fedora 23 is already at 0.23.0, if they do not build it against
libcurl we should ask them, should be doable.

If we can get all of these working, then F23 should be able to have the latest
subsurface as you want it.

> Thanks for all your help over the years. It's really appreciated. I hope
> we can find a way to continue to keep you interested in Subsurface.

Oh, I haven't left yet, still watching over spam in trac and RFE/bugs on the
webservice if needed ;-)

Pierre


More information about the subsurface mailing list