* Package name : subsurface Version : 4.5.6 Upstream Author : Dirk Hohndel <dirk@hohndel.org> * URL : https://subsurface-divelog.org/ * License : GPL Programming Lang: C++ Description : scuba diving logbook Apparently, subsurface had previously been packaged for Debian but got removed (#789875) due to some questionable wish by upstream (according to their website they consider distribution packaging "deprecated") as well as the problems that were caused by libgit2 having some unstable API. Now it seems that subsurface is however packaged for most (all?) other major distros: https://apps.fedoraproject.org/packages/subsurface https://software.opensuse.org/download.html?project=home:Subsurface-Divelog&package=subsurface https://www.archlinux.org/packages/community/x86_64/subsurface/ https://packages.gentoo.org/packages/app-misc/subsurface So I'm kinda missing the point why it shouldn't be possible to have so for Debian. AFAICS, upstream has anyway factually forked libgit2 and libdivecomputer, so these could be used and the problems mentioned in #789875 would be moot. As for upstream's wish not to package it: Well that seems a bit questionable as for the general open source / distros model. Right now, upstream doesn't even seem to provide packages for Debian but suggests people to use their Ubuntu packages. Also, it seems simply plain wrong to encourage not to use a proper package management system here - Debian users loose any security support and a secure way to get the software not to talk about proper Debian integration and community support. Cheers.
Hello, I was maintaining subsurface in Debian for a while. In subsurface, they keep forking libraries. In Debian, it's not allowed to have source packages containing forked libraries. This is due to the fact that the security team doesn't want to have to find multiple copies of the same bug in libraries which might have slight differencies, and apply fixes in all of the copies. In my opinion it's a very sensible approach. I don't know what the policies in other distributions are, about duplicated source code. Unfortunately in subsurface, they don't care about any of this, and keep forking libraries. While libdivecomputer isn't problematic, because it is the only project using it, libmarble and libgit2 pose a problem, and they are internet facing, so could have security vulnerabilities. Upstream is not willing to help in using the original libraries rather than the forks, so a huge amount of patches is necessary to keep this package in Debian. The alternative is to delete all parts of code that use those libraries, and lose many functionalities. I am not closing this bug, but if anyone is reading this, my advice is to move on and don't try to package it. Best
Hey Salvo. Well I've seen that discussion and upstream seems to be pretty hostile against distributions (and apparently security as well). :-( On the other hand, Debian now unfortunately lacks subsurface packages (while other distros have them, or at least more well integrating repos). So people may simply use the questionable packages provided by upstream (which are for the average user only secured by worthless https), which in turn may again decrease security for people. As you've said, libdivecomputer is probably not the problem, while it's already packaged for Debian, that version seems to be used by at least no package. And marble and libgit2: isn't libgit only used locally for storing the logs? Marble is of course an issue. it would be very sad if one could not longer see the dive sites on the globe. But better than nothing at all. Do you think it's difficult to get subsurface working with the official marble libs? Apart from that, many even major packages in Debian seem to ship their copies of libs (e.g. I think ffmpeg uses many internal copies for which official packages exist). So it's not that uncommon, of course it's a pity, but sometimes better than nothing. Best wishes!
Philippe Cerfon <philcerf@gmail.com> writes: AFAIU, the current subsurface does not require libmarble. I have packaged subsurface for my own use, using system git2, and without the googleearth support. The only embedded library is libdivecomputer. I haven't had time to look carefully at how far from policy compliant the package is, but there's obviously a few problems yet. And I don't have any idea how hard it is to get the googlearth plugin working; it's not a priority for me. My work in progress is at https://salsa.debian.org/bremner/subsurface.git For now, it works well enough for my needs. I'm happy to take merge requests, and maybe consider uploading it to debian if it gets to a decent state. If you have dgit, devscripts and sbuild installed, you can build a package with git clone https://salsa.debian.org/bremner/subsurface.git cd subsurface git deborig dgit sbuild d
Hey David. I've just seen your replace from 4 years ago now[0]. O;-) Are you still working on this? Would love to see subsurface coming back to Debian, cause right now I think there is not divecomputer/log software in it at all. It seems libdivecomputer has also been gone from Debian :-( ;ay however also be an advantage - I vaguely remember that Salvo mentioned subsurface would use its own forked version of that which caused him quite some pain in maintaining. Thanks, Philippe. [0] Not a coincidence now - I'm planning a bigger dive safari ;-)
btw... I've just seen there's: http://ppa.launchpad.net/subsurface/subsurface/ubuntu (including packaging for all the deps) So maybe, it could be much simpler to get this back into Debian, by simply basing the Debian packaging on Ubuntu's.
David Bremner <bremner@debian.org> writes: To be fair, the PPA is kept fairly up to date, while I have not updated my repo on salsa for years. So for personal use on debian, building from that PPA makes sense. Alternatively, there is also https://dfx.at/subsurface-debian/ which is explicitely targetted at debian. Same issue there, I don't think the author is concerned with making the package suitable for Debian.
Philippe Cerfon <philcerf@gmail.com> writes: To be honest, I doubt that helps, since the hard part is not just making packages (my repo on salsa already does that), but making them in a way acceptable to debian policy, which is unlikely to be a priority for a PPA. d
My advice is to forget this. Upstream is really uncooperative and Torvalds went to conferences to talk about this (conveniently forgetting to mention he was depending an unstable library whose author said "Don't use this yet") The video of that conference that happened ages ago is still shared today to "prove" how the distribution model is bad, distro maintainers are mean, and so on. Just my advice. Il giorno dom 22 mag 2022 alle ore 13:58 David Bremner <bremner@debian.org> ha scritto:
Were there any specific concerns in terms of policies left? subsurface seems rather simple to me, the only bigger point perhaps being the issue with libdivecomputer. But not since the "official" one is even gone from Debian, it shouldn't be to hard to make a point for a libdivecomputer-subsurface or so, when one could argue that this is really a fork and thus acceptable for Debian.
Well also had some interactions with upstream in the past and it felt indeed a bit "difficult". So I can kinda understand your frustration. Nevertheless, that upstream may be a bit distribution-unfriendly doesn't make subsurface itself less usable. I'd say it's still among the "best" software for diving in the FLOSS world - and that "market" isn't so big, so people cannot just easily choose any other random software (none if which would be packaged for Debian either). In the end, divers will just resort to some unofficial packages (security issues) or IMO questionable systems like snap. So I think there would be some value to get that officially packaged. Thanks, Philippe
Philippe Cerfon <philcerf@gmail.com> writes:
I have not looked very closely. Some issues I am aware of
1) As discussed, libdivecomputer. From subsurface INSTALL
Subsurface requires its own flavor of libdivecomputer which is inclduded
above as git submodule
The branches won't have a pretty history and will include ugly merges,
but they should always allow a fast forward pull that tracks what we
believe developers should build against. All our patches are contained
in the "Subsurface-DS9" branch.
This should allow distros to see which patches we have applied on top of
upstream. They will receive force pushes as we rebase to newer versions of
upstream so they are not ideal for ongoing development (but they are of
course easy to use for distributions as they always build "from scratch",
anyway).
The rationale for this is that we have no intention of forking the
project. We simply are adding a few patches on top of their latest
version and want to do so in a manner that is both easy for our
developers who try to keep them updated frequently, and anyone packaging
Subsurface or trying to understand what we have done relative to their
respective upstreams.
1.5) Submodules are a pain for most Debian workflows (except those that
ignore the git repo).
2) There is minified js in themes/