Re. subsurface: FTBFS in experimental

Dirk Hohndel dirk at hohndel.org
Wed Aug 26 07:37:01 PDT 2015


Hi Pierre,

On Wed, Aug 26, 2015 at 04:20:16PM +0200, Pierre-Yves Chibon wrote:
> 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

I don't really have an issue with that.

> 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/ )

Much nicer than the experience they have today...

Would you help me to get things set up so I can do this? The server all of
my non-Mac builds run on happens to be a Ubuntu system. Is that an issue?
Can I push things into copr from Ubuntu or do I need to be on Fedora?
I can always setup a VM...

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

That's already done with libssrfmarble - it happily coexists with libmarble.
So far I hadn't done that for libdivecomputer as we usually just linked
against that statically (actually, I'm not sure that's true for all of our
builds, but it should be true for all of our Linux builds).

Since libgit2 and libgrantlee have no patches from us I don't think that's
necessary for those - let me know if I'm wrong there.

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

Yeah, that's one of the reasons we have our own version. 0.4.2 was tagged
1.5 years ago (February 6, 2014). It's missing support for a number of
current dive computers and many many bug fixes.

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

If it would make things easier I could file bugs in the libdivecomputer
trac for the two major things missing (string fields and our serial
indirection patches that allow BT support in Subsurface) and create clean
patches on top of the latest libdivecomputer master. That's on my to do
list, anyway.

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

Yes that would be important - that's the only way that libgit2 works
behind a reverse-proxy firewall (so the typical corporate environment
where you can't connect to http/https directly but have to go through a
proxy. That's only in 0.23 and only if built against libcurl.

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

COOL

> > 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 ;-)

Good :-)

Let's make this work.

/D


More information about the subsurface mailing list