Re. subsurface: FTBFS in experimental

[Dirk Hohndel]

On Wed, Aug 26, 2015 at 05:18:16PM +0200, Pierre-Yves Chibon wrote:
> > 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'll set up a VM for that then. I guess this was one of the things I
really liked about using OBS - I can push the changes from my Ubuntu
server and OBS then does its thing :-)

> 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 be happy to use that. I'd love to have the ability to push changes
into that (at least for daily builds) - this makes my life easier.

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

That should be straight forward. Let me know if you run into issues and as
always - patches welcome. This is a bit of an unloved step child. I keep
wanting to make this better and keeping running out of time and out of
steam.

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

I'm sure Jef will love it if I once again push the changes to his mailing
list. Let me talk to him, first. I will create clean patches and file bugs
in his trac.

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

Hard to tell :-)
So the cmake file for libgit2 will default to looking for libcurl if it is
installed. But since it isn't listed as a build requirement I'm not sure
if it is installed or not - i.e., do any of the other build requirements
happen to pull in libcurl-devel? I don't know. It might be nice to
explicitly request it which would ensure that this works.

/D