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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
