[Pkg-running-devel] Bug#789875: subsurface: FTBFS in experimental

[Salvo Tomaselli]

Hello,

can we please stop?

Christoph, if you want to take over subsurface in debian you can. But
patches that need to be maintained are going to be huge; it is a lot
of work. If you don't intend to do this work you can stop using it,
compile their source code or get their binaries. Either way this
discussion is pointless.

Anton, I don't get your sarcasm about the lower level of experience
that subsurface gives in debian. Subsurface is no longer in debian.

Dirk, about the personal attacks and insults. From what I can see you
got them from somebody who is not a debian developer nor maintainer.

Best to all :)

2015-08-26 22:38 GMT+02:00 Anton Lundin <glance at acc.umu.se>:
> On 26 August, 2015 - Christoph Anton Mitterer wrote:
>
>> On Tue, 2015-08-25 at 17:55 -0700, Dirk Hohndel wrote:
>
> ...
>
>> > An application should be able to bring its own libraries for those
>> > libraries that it is so tightly coupled with that it makes no sense
>> > to
>> > allow random combinations. So today Subsurface prefers to run against
>> > our
>> > own branch of libdivecoputer and our own branch of libmarblewidget
>> > and
>> > requires the very VERY latest libgit2 (0.23) and libgrantlee (5.0.0).
>> I think you're surely not the only program which has tightly coupled
>> 3rd party libraries - yet other projects apoarently manage to properly
>> deal with that...
>> Either they find a way to better cooperate with the 3rd party libs
>> respective upstreams and get their needs into that code (as it could
>> perhaps be done with libdivecomputer),... or they take over / fork an
>> anyway slowly maintained project (again, libdivecomputer?),... or they
>> simply use other libraries which better serve there needs (Robert
>> complained about libmarble beeing buggy[0] - why not just using
>> something much simpler? marble seems to be anyway overkill for
>> something like subsurface).
>>
>> And even *if* you say that a fork is really needed for certain libs,
>> why not doing it properly?
>> As Salvo said, "The problem is caused by the fact that
>> subsurface forked some libraries and made them incompatible, without
>> changing the name."
>>
>> This isn't just bad, it's also quite hostile against the original
>> libdivecomputer... and sounds quite like the ffmpeg/libav debacle.
>>
>
> Wtf. Have you even tried to build subsurface? Subsurface builds just
> fine with Jef's libdivecomputer master. Stop whining about
> incompatibilities that aren't there.
>
> And, yes, subsurface has a branch of patches which Jef haven't accepted
> upstream. They make lots of sense to subsurface, and thats why we
> insist on subsurface being distributed to users include them.
>
> And, no there is no hostilities between the top tree contributors of
> libdivecomputer. There are some different points of views as in all
> healthy projects, but as far as hostilities go, your're the most
> hostile thing that exists to that project.
>
> And, yes, Jef, Dirk and I are the top tree contributors to
> libdivecomputer.
>
>> libgit,... well I'm not really into the subsurface code, but I never
>> understood why you introduced that as a storage backend.
>> Even the most prolific divers I know don't have more then 30k-50k
>> dives, and usually these people stopped logging there day to day dives
>> decades ago.
>
> Out of which ass did you pull that statement? My xml file was some
> unpleasant 14Mb of data.
>
> And yes, the git based backend makes sense for the user story that a
> user would like to have and edit their data on more than one machine /
> device.
>
>> Using a plain XML file or poor-man's DB like sqlite should be more than
>> enough ... plus it would have the advantage that one can actually
>> manually edit/parse the log without big problems.
>> I had a few cases where I manually needed to merge dives and realign
>> their timestamps... too rarely to write a proper code for handling such
>> cases, but simple to script with a backend like XML.
>>
>
> So, do you plan to write another storage backend which we can use for
> multiple concurent offline edits? stfu until then.
>
> And editing the data in the git-format is easier on the eyes than
> editing the xml. You use git mv on a directory to change the start time
> of a dive.
>
>> libmarble,... I would rather not have a fancy globe at all and
>> therefore the program packaged properly in the various distros.
>> Actually there are even many more divelog related features one would
>> miss much more (logging of the used equipment, attaching/linking
>> pictures, logging of divecomputer [firmeware] settings, etc. pp.) than
>> a map.
>>
>
> So, you're now the one deciding on what the "user" wants and not?
>
> You're free to fork the project then, but until then, whats the problem
> packaging libssrfmarblewidget.so together with subsurface as we
> suggested?
>
> If you don't like to see the globe, hide it then, but don't break the
> software for anyone who would like to use it.
>
>> libdivecomputer:
>> Wasn't the whole idea of it to have a _central_ FLOSS lib which allows
>> any program to easily access dive computers instead of having one piece
>> of different lib/code (each with different API) per model?
>> Now we basically have the same again,.. the "official" libdivecomputer
>> and the subsurface internal fork?!
>> Also, Robert said, the problem is that the original libdivecomputer
>> isn't too fast, right?
>> I'd guess the ABI itself doesn't change daily in such lib, and if the
>> distro packaged version is older and supports fewer computers... who
>> cares?
>> And let's be honest,... dive computers aren't smartphones. There isn't
>> a new model every week.
>>
>
> Lots of users care, and yes, there are new dive computers on the market
> about every month or so.
>
> "Oh, hey, you can now update your firmware in your ostc devices with
> subsurface, unless you're using Debian."
>
>
> What a awesome experience for your Debian users, not.
>
>
>
> //Anton - Who grew tired of arguing against more FUD
>
>
> --
> Anton Lundin    +46702-161604
>
> _______________________________________________
> Pkg-running-devel mailing list
> Pkg-running-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-running-devel