Re. subsurface: FTBFS in experimental

[Pierre-Yves Chibon]

On Wed, Aug 26, 2015 at 07:37:01AM -0700, Dirk Hohndel wrote:
> 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...

Copr can be used from any system but you would need a way to generate the srpm
so Fedora might be nicer.
I already have a repo on copr (that I should give more love to), maybe we can
start by re-using it. It should also provide a good base to see what needs to be
done to get subsurface working on F23.

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

Cool, then I'll just see at packaging libssrfmarble :)

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

Being able to say: these patches have all been submitted upstream would be nice.
Since I maintain the package and it's already in Fedora, it would not need to be
reviewed so I could just include the patches and make a new release, but I'd
prefer to be able to say that the patches added and being incorporated upstream.

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

Ok cool that simplifies things :)

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

Cf above :)

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

http://pkgs.fedoraproject.org/cgit/libgit2.git/tree/libgit2.spec this is the
current specfile.
I don't see a reference to libcurl, is it done automatically?
If not, do you want to report the issue on bugzilla.redhat.com or shall I?

Thanks,
Pierre