Debian Bug report logs - #789875
subsurface: FTBFS in experimental

Package: src:subsurface; Maintainer for src:subsurface is (unknown);

Reported by: Andreas Beckmann <anbe@debian.org>

Date: Thu, 25 Jun 2015 01:09:02 UTC

Severity: serious

Tags: wontfix

Found in version subsurface/4.3-1~exp1

Fixed in version 4.2-5+rm

Done: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, Debian running development group <pkg-running-devel@lists.alioth.debian.org>:
Bug#789875; Package src:subsurface. (Thu, 25 Jun 2015 01:09:05 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Beckmann <anbe@debian.org>:
New Bug report received and forwarded. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Thu, 25 Jun 2015 01:09:05 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Source: subsurface
Version: 4.3-1~exp1
Severity: serious

subsurface FTBFS against recent libgit:

compiling save-git.c
save-git.c: In function 'new_directory':
save-git.c:480:2: warning: implicit declaration of function 'git_treebuilder_create' [-Wimplicit-function-declaration]
  git_treebuilder_create(&subdir->files, NULL);
  ^
save-git.c: In function 'write_git_tree':
save-git.c:1059:38: warning: passing argument 2 of 'git_treebuilder_write' from incompatible pointer type
  ret = git_treebuilder_write(result, repo, tree->files);
                                      ^
In file included from /usr/include/git2/diff.h:13:0,
                 from /usr/include/git2/checkout.h:12,
                 from /usr/include/git2.h:17,
                 from save-git.c:11:
/usr/include/git2/tree.h:375:17: note: expected 'struct git_treebuilder *' but argument is of type 'struct git_repository *'
 GIT_EXTERN(int) git_treebuilder_write(
                 ^
save-git.c:1059:8: error: too many arguments to function 'git_treebuilder_write'
  ret = git_treebuilder_write(result, repo, tree->files);
        ^
In file included from /usr/include/git2/diff.h:13:0,
                 from /usr/include/git2/checkout.h:12,
                 from /usr/include/git2.h:17,
                 from save-git.c:11:
/usr/include/git2/tree.h:375:17: note: declared here
 GIT_EXTERN(int) git_treebuilder_write(
                 ^
Makefile:1671: recipe for target '.obj/save-git.o' failed
make[1]: *** [.obj/save-git.o] Error 1
make[1]: Leaving directory '/tmp/buildd/subsurface-4.3'
dh_auto_build: make -j1 returned exit code 2
debian/rules:6: recipe for target 'build' failed
make: *** [build] Error 25


Andreas

Information forwarded to debian-bugs-dist@lists.debian.org, Debian running development group <pkg-running-devel@lists.alioth.debian.org>:
Bug#789875; Package src:subsurface. (Wed, 12 Aug 2015 07:39:13 GMT) (full text, mbox, link).

Acknowledgement sent to Salvo Tomaselli <tiposchi@tiscali.it>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Wed, 12 Aug 2015 07:39:13 GMT) (full text, mbox, link).

Message #10 received at 789875@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

tags: wontfix
thanks


Libgit2 breaks API at every minor release.

Subsurface insists on using it.

Subsurface's upstream does not like distributions and will make packaging more 
and more difficult on purpose, to discourage distributions from packaging it.

https://www.mail-archive.com/subsurface@subsurface-divelog.org/msg05634.html

Honestly, there is nothing I can do, that doesn't involve forking subsurface.

Sorry

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

http://ltworf.github.io/ltworf/

[signature.asc (application/pgp-signature, inline)]

Added tag(s) wontfix. Request was from Salvo Tomaselli <tiposchi@tiscali.it> to control@bugs.debian.org. (Wed, 12 Aug 2015 07:54:04 GMT) (full text, mbox, link).

Acknowledgement sent to Christian PERRIER <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Wed, 12 Aug 2015 12:24:03 GMT) (full text, mbox, link).

Message #17 received at 789875@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Quoting Salvo Tomaselli (tiposchi@tiscali.it):
> tags: wontfix
> thanks
> 
> 
> Libgit2 breaks API at every minor release.
> 
> Subsurface insists on using it.
> 
> Subsurface's upstream does not like distributions and will make packaging more 
> and more difficult on purpose, to discourage distributions from packaging it.
> 
> https://www.mail-archive.com/subsurface@subsurface-divelog.org/msg05634.html
> 
> Honestly, there is nothing I can do, that doesn't involve forking subsurface.
> 
> Sorry

Agreed. Stop dealing with that upstream ("I believe that the
design of most Linux distros is fundamentally broken" : how arrogant
is that) and let's throw subsurface away as it is....or just fork it
to make it distro-friendly.

Just leave this guy (these guys) play with they hobby, manually compile each
and every software that comes on their machines and live in their own
broken world.

I very much understand your bitterness, Salvio. You did great work
packaging this software and it will be lost.

I very very very seldomly became aggressive in dozens of years on free
software but that issue is among those that drive me to the Dark
Side. Sorry for this.

May I suggest you now choose running instead of scuba diving: we have
plenty of great running software in Debian and they are very
distro-friendly...:-)

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Sylvestre Ledru <sylvestre@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Wed, 12 Aug 2015 12:45:04 GMT) (full text, mbox, link).

Message #22 received at 789875@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Le 12/08/2015 09:30, Salvo Tomaselli a écrit :
> tags: wontfix
> thanks
>
>
> Libgit2 breaks API at every minor release.
>
> Subsurface insists on using it.
>
> Subsurface's upstream does not like distributions and will make packaging more 
> and more difficult on purpose, to discourage distributions from packaging it.
>
> https://www.mail-archive.com/subsurface@subsurface-divelog.org/msg05634.html
>
> Honestly, there is nothing I can do, that doesn't involve forking subsurface.
>
> Sorry
>
:(
I reported bug #795267 for the removal.


Cheers,
Sylvestre

[signature.asc (application/pgp-signature, attachment)]

Acknowledgement sent to Dirk Hohndel <dirk@hohndel.org>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Wed, 12 Aug 2015 15:00:08 GMT) (full text, mbox, link).

Message #27 received at 789875@bugs.debian.org (full text, mbox, reply):

On Wed, Aug 12, 2015 at 02:20:47PM +0200, Christian PERRIER wrote:
> Quoting Salvo Tomaselli (tiposchi@tiscali.it):
> > tags: wontfix
> > thanks
> > 
> > 
> > Libgit2 breaks API at every minor release.
> > 
> > Subsurface insists on using it.
> > 
> > Subsurface's upstream does not like distributions and will make packaging more 
> > and more difficult on purpose, to discourage distributions from packaging it.
> > 
> > https://www.mail-archive.com/subsurface@subsurface-divelog.org/msg05634.html
> > 
> > Honestly, there is nothing I can do, that doesn't involve forking subsurface.
> > 
> > Sorry
> 
> Agreed. Stop dealing with that upstream ("I believe that the
> design of most Linux distros is fundamentally broken" : how arrogant
> is that) and let's throw subsurface away as it is....or just fork it
> to make it distro-friendly.

I guess we agree to disagree.

> Just leave this guy (these guys) play with they hobby, manually compile each
> and every software that comes on their machines and live in their own
> broken world.
> 
> I very much understand your bitterness, Salvio. You did great work
> packaging this software and it will be lost.
> 
> I very very very seldomly became aggressive in dozens of years on free
> software but that issue is among those that drive me to the Dark
> Side. Sorry for this.

Sorry we are making you aggressive. We are just trying to create the best
possible experience for our users. And the current model that
distributions use when it comes to applications and the libraries that
they depend on doesn't allow us to do so.

That's why we politely ask the distributions not to ship versions of
Subsurface that don't provide the same user experience as our binaries
provide.

You are more than welcome to fork Subsurface - we politely ask that you
use a different project name if you do that to avoid confusing users.

Anyway, thanks for removing Subsurface from Debian.

/D

Acknowledgement sent to Robert Helling <helling@atdotde.de>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Wed, 12 Aug 2015 15:00:10 GMT) (full text, mbox, link).

Message #32 received at 789875@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

> On 12.08.2015, at 14:20, Christian PERRIER <bubulle@debian.org> wrote:
> 
> Agreed. Stop dealing with that upstream ("I believe that the
> design of most Linux distros is fundamentally broken" : how arrogant
> is that) and let's throw subsurface away as it is....or just fork it
> to make it distro-friendly.

there is a lot of anger that has accumulated over a long time in these statements.

Maybe it’s worthwhile to spell this out more explicitly since not everybody understands their basis and just sees the arrogance:

Subsurface decided to use a number of libraries including libdivecomputer (to be able to talk to a large number of dive computers), libgit2 (to be able to store its user data in git repositories) and libmarble (to show maps of dive sites).

By now, for all three we cannot easily rely on versions that come with distributions, for various reasons: libgit2 keeps changing its API at random times, even linking against a given version number does not ensure you find the API you expect. This means, a program basically has to know the commit of that library that it is linked against to be able to reliably talk to it. Plus, major distributions still provided very old versions of this library that were simply too buggy or missing essential features to be useful.

libmarble is a huge beast that keeps throwing bogus error messages when used from other programs than the main marble program. Plus they are not really too responsive when it comes to merge upstream patches for errors. So we decided to fork a lightweight version of it.

Libdivecomputer is also not too fast when it comes to merging patches which would imply that we would seriously limit the number of compatible dive computers that subsurface can talk to if we relied on the packaged version.

Therefore, to be able to provide our users with the best experience, we decided to compile our own versions of these libraries (some of them forks).

Being allowed to to that in a distribution (e.g. by allowing to link these statically) would make packaging subsurface much easier. Of course, in a distribution you don’t want all programs to statically link all libraries since that would defeat the purpose of having libraries, but if the versioning is so fragile, we don’t see an alternative. In particular when it comes to libraries where subsurface is likely the only program that uses them (check for yourself, which packages require these libraries in Debian?

Best
Robert

--
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics
                      Scientific Coordinator
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik
                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
                      http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F

[Message part 2 (text/html, inline)]

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian running development group <pkg-running-devel@lists.alioth.debian.org>:
Bug#789875; Package src:subsurface. (Fri, 14 Aug 2015 12:15:03 GMT) (full text, mbox, link).

Acknowledgement sent to Salvo Tomaselli <tiposchi@tiscali.it>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Fri, 14 Aug 2015 12:15:03 GMT) (full text, mbox, link).

Message #37 received at 789875@bugs.debian.org (full text, mbox, reply):

> Of course, in a distribution you donât want all programs to statically
> link all libraries since that would defeat the purpose of having libraries
> but if the versioning is so fragile, we donât see an alternative.

Debian allows static linking. The problem is caused by the fact that 
subsurface forked some libraries and made them incompatible, without changing 
the name.

Debian, as a general rule, disallows duplicated source packages. But since the 
incompatible forks retain the same name, they could never coexist within the 
same machine with the original library.

This is what makes packaging impossible. Not the static linking.

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

http://ltworf.github.io/ltworf/

Reply sent to Debian FTP Masters <ftpmaster@ftp-master.debian.org>:
You have taken responsibility. (Sun, 16 Aug 2015 21:39:24 GMT) (full text, mbox, link).

Notification sent to Andreas Beckmann <anbe@debian.org>:
Bug acknowledged by developer. (Sun, 16 Aug 2015 21:39:24 GMT) (full text, mbox, link).

Message #42 received at 789875-done@bugs.debian.org (full text, mbox, reply):

Version: 4.2-5+rm

Dear submitter,

as the package subsurface has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/795267

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Wed, 26 Aug 2015 00:12:03 GMT) (full text, mbox, link).

Message #47 received at 789875@bugs.debian.org (full text, mbox, reply):

Hey.

How saddening to see such a nice program for divers being basically
destroyed by a stupid and arrogant upstream (and while some may
consider this impolite, I guess it's simply the truth).

Especially the assumption to know it better than the rest of the whole
opensource world and decades of proven philosophy and even claiming
that this would increase the "experience" for users is just weird.
Well apparently subsurface is now targeted towards Win/Mac[0] (no
binaries for Linux)... so the "experience" for FLOSS users will simply
be that there is no subsurface anymore.
And a "nice" side effect for those poor souls which actually bother to
use the upstream binaries or compile from sources is to have no code in
their system which evades the proper package management system and any
for of security support.. but maybe upstream donates it some windows
-like per-program-update-code o.O


>And the current model that
>distributions use when it comes to applications and the libraries that
>they depend on doesn't allow us to do so.
Probably everyone here is curious about some enlightenment how upstream
thinks software management should happen! Appstores? MSI installer
files? All statically linked?

I really regret nowadays to have spent time on debugging some data
corruption issues in subsurface logs (which were anyway never fully
fixed).




Anyway,.. thanks to the Debian maintainers for keeping it as long as
possible in the archives.

Have you considered to simply build without git support (I love git,
but using it as a backend here seemed just ugly and I always liked the
xml file much more) and disable marble?
Then it would be just libdivecomputer, and AFAIR nothing in Debian uses
the systemwide package (except subsurface).



Cheers,
Chris.


[0] And I really wonder which divers from that community are going to
use subsurface instead of the native dive logs... I know quite a number
of divers, both tec and recreational, and none from the non-FLOSS side
uses subsurface; great binary-installer-experience or not.

Message #52 received at 789875@bugs.debian.org (full text, mbox, reply):

On Wed, Aug 26, 2015 at 02:10:06AM +0200, Christoph Anton Mitterer wrote:
> 
> How saddening to see such a nice program for divers being basically
> destroyed by a stupid and arrogant upstream (and while some may
> consider this impolite, I guess it's simply the truth).

You are entitled to your opinion.
Being called stupid and arrogant is usually not a great conversation
opener, but hey, I've been called worse.

> Especially the assumption to know it better than the rest of the whole
> opensource world and decades of proven philosophy and even claiming
> that this would increase the "experience" for users is just weird.

And because of those decades of proven philisophy Linux has taken over the
desktop, correct? And become the #1 targeted platform of all major desktop
applications.

Sorry, that was snarky and I had promised myself not to be snarky but to
be constructive. So let's strike that last comment.

> Well apparently subsurface is now targeted towards Win/Mac[0] (no
> binaries for Linux)... so the "experience" for FLOSS users will simply
> be that there is no subsurface anymore.

No, we have binaries available for Ubuntu, Fedora, OpenSUSE, Mint, and, of
course, Debian. And we have a fully automated build script in the works
that builds Subsurface on many other distributions that we haven't been
able to add to our list. There's an ArchLinux AUR based on that. Etc.

> And a "nice" side effect for those poor souls which actually bother to
> use the upstream binaries or compile from sources is to have no code in
> their system which evades the proper package management system and any
> for of security support.. but maybe upstream donates it some windows
> -like per-program-update-code o.O

So looking at my stats 4x as many Debian users are using the binaries we
provide than the binaries that used to come with the distribution. But as
a matter of fact both of those combined are less than 1% of our user base.

And of course for the vast majority of our libraries we use the system
installed ones so the users do indeed benefit from any security updates
that will happen in the distribution.

> >And the current model that
> >distributions use when it comes to applications and the libraries that
> >they depend on doesn't allow us to do so.
> Probably everyone here is curious about some enlightenment how upstream
> thinks software management should happen! Appstores? MSI installer
> files? All statically linked?

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

We link against 107 libraries (today's master, checked on ArchLinux).
There are four libraries that we want to control - everything else we
should be fine with a reasonably current distribution (ok, for Qt you
won't get all of our features if you aren't on 5.3 or newer).

> I really regret nowadays to have spent time on debugging some data
> corruption issues in subsurface logs (which were anyway never fully
> fixed).

So that made me curious. There is a sum total of ONE email from you on the
mailing list, the beginning of which I'm quoting here:

	On Mon, 2014-03-17 at 21:27 +0100, Rainer Mohr wrote:
	> May I ask how you are involved in Subsurface, I didn't find you on the
	> mailing list?
	I'm not,.. but it's opensource any everyone could contribute... not sure
	whether I find the time to actually write a parser, but I've opened a
	ticket some time ago about this and it makes sense to collect such
	information there.

So you opened a ticket and we didn't fix it for you.
I appreciate your contributions to Subsurface. Thank you.

> Anyway,.. thanks to the Debian maintainers for keeping it as long as
> possible in the archives.

Yes, thanks to the maintainers - I appreciate the work that they have done
and I continue to use a big chunk of the packaging work done by them in
order to create the Debian / Ubuntu packages that are available.

> Have you considered to simply build without git support (I love git,
> but using it as a backend here seemed just ugly and I always liked the
> xml file much more) and disable marble?

That will give you the reduced user experience that we are trying to
avoid. You are of course welcome to do that. We would appreciate if you
didn't call it Subsurface if you did that, though.

> [0] And I really wonder which divers from that community are going to
> use subsurface instead of the native dive logs... I know quite a number
> of divers, both tec and recreational, and none from the non-FLOSS side
> uses subsurface; great binary-installer-experience or not.

About 15% of our users are on Linux - this has been fairly consistent for
the past two years during which I have been trying to track those numbers.

And since none of the native dive logs are running on Linux (and the other
dive log software that appears to exist under Linux is, frankly, a joke
and not really usable), my guess is that Linux users are much more
motivated to use Subsurface than Windows or Mac users (where there usually
is a vendor app and of course there are other vendor independent dive logs
available like MacDive and DivingLog).

Anyway, I'm not trying to argue with you. I understand your feelings and
the frustration that Subsurface is violating some of your strongly held
believes. I was simply trying to insert a little more data into the
conversation.

If you have a solution that would allow us to tightly control about a
handful of libraries that we link against that would work for Debian, I'll
be happy to work with you. But given that libgit2 has been deemed
insufficiently portlable and mature by Debian (yet it's the underlying
mechanism that we use for our upcoming cloud storage feature in Subsurface
4.5) I am not hopeful that this will end up being easy.

/D

Message #57 received at 789875@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Tue, 2015-08-25 at 17:55 -0700, Dirk Hohndel wrote:
> Being called stupid and arrogant is usually not a great conversation
> opener, but hey, I've been called worse.
Well I should have probably immediately apologised along the way, just
for the sake of politeness...

But the believe to know it much better than everyone else apparently
does qualifies quite well for arrogance.
And intentionally trying/wishing to keep the distros, while these are
at the same time the major and preferred way of software distribution
for the whole community where oneself comes from... for sure you know
the German saying "an dem Ast sägen auf dem man sitzt"... so I guess
that qualifies quite well for not making the smartest decisions.

> And because of those decades of proven philisophy Linux has taken 
> over the
> desktop, correct? And become the #1 targeted platform of all major 
> desktop
> applications.

Well the reason for this is for sure not that we have proper package
management systems and repositories... something which especially the
Windows world never really managed to do and which causes them quite
some problems - while everything which has them (or the
proprietary/evil versions of them, aka appstores) is quite successful
with them.

And apart from that,... if one wants to be like Windows or like Mac,
than the best is probably just to use these, ain't it?
I guess many people in the FLOSS world are actually quite happy with
Linux not having the 99% market share.
As the past has sown over and over again (even within FLOSS, take GNOME
as an exmaple): software with a too high market share tend to get evil,
broken or are simply targeted towards end-end-end-users and no longer
professionally usable.

> Sorry, that was snarky and I had promised myself not to be snarky but 
> to
> be constructive. So let's strike that last comment.
Yeah,... let's not go into completely unrelated topics...

> No, we have binaries available for Ubuntu, Fedora, OpenSUSE, Mint, 
> and, of
> course, Debian.
Then your download page is probably out of date, which still claims:
>Linux
>The Subsurface team is starting to make our own dedicated binaries
>available for a number of Linux versions.

It apparently misses Fedora and Mint, and Debian seems to be simply the
*buntu package?

Anyway,... I probably can't speak for all possible users but I'm quite
sure I'm not alone in not using such binaries by principle.
That's why distros exist, that people don't have to
maintain/upgrade/etc. all software themselves.
Not to talk about the security nightmares that your model of software
distribution brings along.

> So looking at my stats 4x as many Debian users are using the binaries 
> we
> provide than the binaries that used to come with the distribution. 
> But as
> a matter of fact both of those combined are less than 1% of our user 
> base.
And how do you get your stats? Making stats which are actually
representative and don't just show what one wants to see isn't that
easy.
popcon is probably no guarantee, as it's not installed per default.

End even if representative statistics would show that the upstream
binaries are used more than the distro ones, than the reason may just
be the artificial ones you've created yourself, by making subsurface
difficult to package and thus outdated in distros.

> And of course for the vast majority of our libraries we use the 
> system
> installed ones so the users do indeed benefit from any security 
> updates
> that will happen in the distribution.
Security isn't just in terms of up-to-date 3rd party libraries.
subsurface itself may have vulnerabilities and it wouldn't be the first
project whose website gets hacked and has forged binaries distributed.

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

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

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.

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.

> There are four libraries that we want to control
Then - even if the alternatives I've named above would be probably
better - properly fork them.
For libdivecomputer you have even good chances that your fork would
become the main fork.

And distro maintainers have at least somewhat better chances with their
work. (I still could imagine that the release managers and security
team wouldn't be all to happy about such forks).

> 
> So that made me curious. There is a sum total of ONE email from you 
> on the
> mailing list, the beginning of which I'm quoting here:

Uhm I hade quite a number of bugs/enhancement[1] ideas open in track,
some of them fixed some of them not... we two even communicated several
times over some of them.

Actually I couldn't even remember that I used the ML the one time.

> That will give you the reduced user experience that we are trying to
> avoid.
Well, better some than no experience at all, right?
The later which is especially bad for all those people who thought that
subsurface would be something that is here to stay and have now all
their logs in it.
:-(

>  You are of course welcome to do that. We would appreciate if you
> didn't call it Subsurface if you did that, though.
Is it already trademarked and patented?! ;-)

Reminds me a bit to Mozilla, where the lawyers may have already knocked
on your doors when you changed a line of code and still named it FF.
O:D

> About 15% of our users are on Linux - this has been fairly consistent 
> for
> the past two years during which I have been trying to track those 
> numbers.
Again, I'm a bit curious how you track those numbers? Does subsurface
phone home?
Or is it by downloads (which again would likely be biased - because why
should Linux users download a package, when they have it in their
distro)?

> And since none of the native dive logs are running on Linux (and the 
> other
> dive log software that appears to exist under Linux is, frankly, a 
> joke
> and not really usable), my guess is that Linux users are much more
> motivated to use Subsurface than Windows or Mac users (where there 
> usually
> is a vendor app and of course there are other vendor independent dive 
> logs
> available like MacDive and DivingLog).
I haven't said that Linux users weren't motivated to use subsurface...
actually that was just my point, when I said that you make it much
harder for them now to use subsurface - they typically have no
alternative.

> If you have a solution that would allow us to tightly control about a
> handful of libraries that we link against that would work for Debian
Several options have been named,...

> I'll
> be happy to work with you.
Well in then end it wouldn't be me you'd have to work with but the
current/previous maintainers of subsurface of Debian.
And at least I - from my PoV - could understand if they're no longer
keen on working with a upstream which basically said he doesn't want to
have distros ship his program and to emphasise this wish he'd even make
their lives harder to do so.

> (yet it's the
> underlying
> mechanism that we use for our upcoming cloud storage feature in 
> Subsurface
> 4.5)
JFTR: I wouldn't want all my dives to be spied upon in the cloud :) ...
so if that was going to be a core / unavoidable part of subsurface, I
would anyway loose my interest.

Best wishes,
Chris.
(who is actually about to head into a one month vacation of tec
diving,... now unfortunately without a diving log software :-( )

[0] btw: funny that the subsurface side complains about something
hardly usable from "outside" (i.e. when not being the the main marble
program), while they actively try themselves to make using their stuff
more difficult for others :D

[1] #180, #181, #192,#193, #194, #198, #440, #453, #454, #649, #672,
#684

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #62 received at 789875@bugs.debian.org (full text, mbox, reply):

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


Christoph may have a point, here, indeed. 

I'm not a diver. For the record, I jumped in this thread because
subsurface is/was team-maintained in Debian by a team historically
named "pkg-running", which actually tries to deal with packaging of
sports-related end-user applications. 

I'm a runner and, indeed I use similar software to track down my runs
and trainings. I run daily, which means I have thousands of recorded
trainings after 10 years of practice.

And, well, the software I'm using does actually use SQLite for storing
its data, and is perfectly fine with that.

For sure, I well understand that redisigning Subsurface to use a
different storage backend is not something one can reasonably consider
but maybe having this as an option could be nice. Of course, that
requires someone to do the work and "patches welcomed" answers are
perfectly fine.

Whatever future happens, I use this opportunity to thank all
contributors in this mini thread for their politeness despite the
diverging opinions....and also send a mini apology for having been
kinda rude....I do share Christoph's feeling about the "raison d'être"
of distros and, well, I'm never happy when this is not well understood....

Acknowledgement sent to "Lubomir I. Ivanov" <neolit123@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Wed, 26 Aug 2015 10:45:10 GMT) (full text, mbox, link).

Message #67 received at 789875@bugs.debian.org (full text, mbox, reply):

On 26 August 2015 at 05:38, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> On Tue, 2015-08-25 at 17:55 -0700, Dirk Hohndel wrote:
>> Being called stupid and arrogant is usually not a great conversation
>> opener, but hey, I've been called worse.
> Well I should have probably immediately apologised along the way, just
> for the sake of politeness...
>
> But the believe to know it much better than everyone else apparently
> does qualifies quite well for arrogance.
> And intentionally trying/wishing to keep the distros, while these are
> at the same time the major and preferred way of software distribution
> for the whole community where oneself comes from... for sure you know
> the German saying "an dem Ast sägen auf dem man sitzt"... so I guess
> that qualifies quite well for not making the smartest decisions.
>
>

your approach for convincing is offensive and unwise.

i'm getting the notion that the Linux distribution maintainers are
simply buthurt for the fact that Linus Torvalds started Subsurface and
as a peace of software it now no longer obeys the Linux distribution
rules; it's setting a bad example at the expense of not being
available everywhere at anytime in the ecosystem.

otherwise, why would you even care if some odd divelog software is no
longer distributed by distro X?

not only the Subsurface mailing list, but surely there are other
people who believe that the most portable kernel (Linux) is wrapped by
distributions in stubborn ideology and separation, which makes
software non-portable...and by non-portable i don't mean "but it can
be *built* everywhere and distributed by our package tools", i mean,
how about:

*) copy-pasting an installer which runs on the same architecture on
multiple distributions and multiple version of the same distribution
from 15 years ago?
*) letting the developer deal with nitsche issues in some horribly
maintained library?

Windows as an OS does that and x86 as modular CPU design also does
that. overhead, bloat and dye space in the expense of portability!

the whole idea of "each distro will build and maintain your software
for you, but it will only run on our distro or child-distros" has the
perspective for job and hobbyist openings and that's *great*, but it
doesn't mean that their work will be focused in the most optimal
software designs ever, architecturally.

lubomir
--

Message #72 received at 789875@bugs.debian.org (full text, mbox, reply):

On Wed, 2015-08-26 at 13:40 +0300, Lubomir I. Ivanov wrote:
> your approach for convincing is offensive and unwise.
Well if upstreams are effectively hostile against core paradigms of the
FLOSS community, it must expect that people won't be happy with it.

> as a peace of software it now no longer obeys the Linux distribution
> rules; it's setting a bad example at the expense of not being
> available everywhere at anytime in the ecosystem.
Being not available is not the problem by itself. There's many software
which is not packaged for Debian.
The problem is when you have projects which intentionally work against
some of the base principles of open source software, as here: the
apparently expressed wish of upstream to be under fully control of the
program (like being the only place where it's been distributed, people
not adapting it without renaming, etc.)

> otherwise, why would you even care if some odd divelog software is no
> longer distributed by distro X?
It's like when DLRS manufacturers bring out a new mount system... they
promise you everything that this will be *their* system for the future.
People start to invest (money) in it,.. and not rarely it happened that
the manufacturer changed the mount some years afterwards.

The point is:
People "invested" in subsurface, in the sense that they stored all
their data in it,... and part of the decision for that may have been
the believe that subsurface acts like any other typical sane open
source project - in this example: not trying to keep distros from
properly packaging software.

If the subsurface people would have said from the beginning:
"This is our nice fancy new diving log software. Use it, but beware
that we want to keep full control (unless you fork) and in 2 years
we'll try to prevent distros from packaging."
than I guess many people (at least myself) would have never used it in
the first place.

On Wed, 2015-08-26 at 08:54 +0200, Christian PERRIER wrote:
> For sure, I well understand that redisigning Subsurface to use a
> different storage backend is not something one can reasonably 
> considerbut maybe having this as an option could be nice.
Actually, the XML backend already exists (or did so?). I even think
it's the only usable backend in the most recent version of the
official[0] Debian package.

> I do share Christoph's feeling about the "raison
> d'être"
> of distros and, well, I'm never happy when this is not well 
> understood....
Well I guess it's perfectly fine and politically simply the best and
only choice to throw out packages that behave bad,... such hostility
against distributions cannot be accepted as it threatens the FLOSS
model at whole.
And IMHO neither distributions nor the community should accept projects
which call themselves open/free, but basically demand full control and
renaming/forking when one starts to change bits of the "experience"[1].

The FLOSS philosophy isn't just about having some open source license,
but on the other hand making it basically impossible to freely use
software as people wish (in this case: properly packaged in
distributions) with the small side node that people could always simply
fork if they're not happy. That's the Oracle way of handling open
source.
So, right choice from Debian,... it's just a pity that all people who
put their trust into subsurface are now kinda screwed.

Best wishes,
Chris.

[0] Official = the one from Debian
[1] Funny, btw, that this rule apparently only applies to downstreams.
If such upstream does the very same, like subsurface changes the
"experience" of libdivecomputer/etc. a rename is apparently not deemed
necessary by them ;-)

Message #77 received at 789875@bugs.debian.org (full text, mbox, reply):

On Wed, Aug 26, 2015 at 04:40:43PM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2015-08-26 at 13:40 +0300, Lubomir I. Ivanov wrote:
> > your approach for convincing is offensive and unwise.
> Well if upstreams are effectively hostile against core paradigms of the
> FLOSS community, it must expect that people won't be happy with it.

Some of us have expressed our dismay with the way distributions work these
days. I used to be the CTO of a distribution company (SuSE). One of the
other outspoken Subsurface developers on this topic (and the guy who
started Subsurface) also has some background with Linux, though he wasn't
ever involved in a distribution...

He actually talked about this at the DebConf in Portland last year:
http://gensho.acc.umu.se/pub/debian-meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm

But let's get real here. We are not "hostile against core paradigms of the
FLOSS community". The hybris in writing things like that is actually kinda
funny. We disagree with the more extreme people in some distributions.

The catholic church had the crusaders, Islam has ISIS, the open source
community has their extremists. Neither of those extremist groups speak
for the whole community. You do not speak for the open source community.
I don't either. Neither do I claim to do so.

> > as a peace of software it now no longer obeys the Linux distribution
> > rules; it's setting a bad example at the expense of not being
> > available everywhere at anytime in the ecosystem.
> Being not available is not the problem by itself. There's many software
> which is not packaged for Debian.
> The problem is when you have projects which intentionally work against
> some of the base principles of open source software, as here: the
> apparently expressed wish of upstream to be under fully control of the
> program (like being the only place where it's been distributed, people
> not adapting it without renaming, etc.)

I politely asked that if you fork it, fork it with a different name.
Just like the Debian community would ask me to use a different name if I
created a derived distribution that included proprietary software. So you
are telling me "do as I say, don't do as I do"?

And again, your definition of "base principles of open source" may not be
shared by a lot of people in the open source community.

> > otherwise, why would you even care if some odd divelog software is no
> > longer distributed by distro X?
> It's like when DLRS manufacturers bring out a new mount system... they
> promise you everything that this will be *their* system for the future.
> People start to invest (money) in it,.. and not rarely it happened that
> the manufacturer changed the mount some years afterwards.
> 
> The point is:
> People "invested" in subsurface, in the sense that they stored all
> their data in it,... and part of the decision for that may have been
> the believe that subsurface acts like any other typical sane open
> source project - in this example: not trying to keep distros from
> properly packaging software.
> 
> If the subsurface people would have said from the beginning:
> "This is our nice fancy new diving log software. Use it, but beware
> that we want to keep full control (unless you fork) and in 2 years
> we'll try to prevent distros from packaging."
> than I guess many people (at least myself) would have never used it in
> the first place.

I'm sorry we mislead you. I don't quite understand how we mislead you. I
don't quite understand how data in our open XML format is similar to
spending money on a DLSR - but I guess we have by now well established
that we are talking past each other.

Subsurface is open source, continues to be open source. It has an active
community of developers and runs on many different OSs and platforms.
Our data format is open, our sources are open source under the GPLv2, no
one is taking anything from you.

We have asked SPECIFICALLY Debian to stop providing an out-dated version
of Subsurface to its users as that caused confusion and problems for our
users and support burdon for us. Debian was unwilling to follow our
choices of open source components that we used. So we asked Debian to drop
bundling Subsurface since we provide a version of Subsurface which a diver
who happens to run Debian and wants to use Subsurface can install.

Here's the funny thing. There aren't a lot of options for a diver looking
for a decent open source dive log. But there are a TON of options for a
diver looking for an OS that supports her needs. And the numbers that we
have clearly show that a tiny fractions of divers seem to think that
Debian is their best choice. And the audience for which Subsurface is
being developed is divers, not Debian maintainers.

> On Wed, 2015-08-26 at 08:54 +0200, Christian PERRIER wrote:
> > For sure, I well understand that redisigning Subsurface to use a
> > different storage backend is not something one can reasonably 
> > considerbut maybe having this as an option could be nice.
> Actually, the XML backend already exists (or did so?). I even think
> it's the only usable backend in the most recent version of the
> official[0] Debian package.

XML still is the default storage format. The git backend was added in
preparation for cloud storage of dive data, which is in return one of the
key features needed before it makes sense to have an Android application.

See, we are interested in what divers would like - and a full fledged
Android app has been very high on the list of things people ask us for...

And now I would have to tell people in the Android store "seamlessly
exchange data with Subsurface 4.5 on the desktop (except Subsurface 4.5 as
shipped by Debian)". That's ridiculous.

You go continue and enjoy the paradigm shifts of your FLOSS world and
revel in your freedoms. In the meantime we are trying to give a open
source option to divers who actually just want their software to work.

> > I do share Christoph's feeling about the "raison
> > d'être"
> > of distros and, well, I'm never happy when this is not well 
> > understood....
> Well I guess it's perfectly fine and politically simply the best and
> only choice to throw out packages that behave bad,... such hostility
> against distributions cannot be accepted as it threatens the FLOSS
> model at whole.

Oh get off your soap box. You are sounding ridiculous by now.

> And IMHO neither distributions nor the community should accept projects
> which call themselves open/free, but basically demand full control and
> renaming/forking when one starts to change bits of the "experience"[1].

Demand? I have politely asked to respect our wishes. I can't stop you from
shipping a pile of dog poop and calling it Subsurface. All I did was ask.

Oh, and you did not "throw out a package that behaved bad". I ASKED that
the package be removed. I asked politely. And in return I received abusive
emails from a number of Debian maintainers. With personal attacks and
insults. True to Debian's reputation, I guess.

> The FLOSS philosophy isn't just about having some open source license,
> but on the other hand making it basically impossible to freely use
> software as people wish (in this case: properly packaged in
> distributions) with the small side node that people could always simply
> fork if they're not happy. That's the Oracle way of handling open
> source.

If by "properly packaged" you mean "broken and incompatible with upstream"
then yes, you are right. If by "freely use" you mean you can use the
software, modify and fork it (which is the definition of open source) then
no, you are wrong.

> So, right choice from Debian,... it's just a pity that all people who
> put their trust into subsurface are now kinda screwed.

They are screwed because Debian maintainers insist on removing features
and refuse to accept upstreams choice of libraries we want to depend on.
They are more than welcome to use the packages that we provide - or switch
to a more sanely run distribution.

I'm talking to the Fedora maintainer right now about getting Subsurface
packaged for Fedora 23.

> [1] Funny, btw, that this rule apparently only applies to downstreams.
> If such upstream does the very same, like subsurface changes the
> "experience" of libdivecomputer/etc. a rename is apparently not deemed
> necessary by them ;-)

Actually I talked to Jef (the libdivecomputer maintainer) about this and
we agreed that this should just be a branch of libdivecomputer, not a
fork. The repository from which you can get our version is named libdc
instead of libdivecomputer in order to avoid confusion, but it's still
just a branch in libdc - libdc master is the same as libdivecomputer
master. Ironically libdivecomputer is even hosted on my infrastructure.

And the moment Jef asks me to change the name I'll be more than happy to
do this. After all it's his project and I prefer to be polite to the
people who maintain the projects I engage with.

Which clearly is not the preferred way for Debian contributors to interact
with the projects they engage with.

Take care and enjoy your freedom

/D

Message #82 received at 789875@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Quoting Dirk Hohndel (dirk@hohndel.org):

> We have asked SPECIFICALLY Debian to stop providing an out-dated version
> of Subsurface to its users as that caused confusion and problems for our
> users and support burdon for us. Debian was unwilling to follow our
> choices of open source components that we used. So we asked Debian to drop
> bundling Subsurface since we provide a version of Subsurface which a diver
> who happens to run Debian and wants to use Subsurface can install.


One hilarious thing in this discussion is seeing how people speak about
"Debian does this" or "Debian chooses that" and then later on give big
details about their big background in "open source" (bleh) software.

That's interesting because it is very common from outsiders of the
Debian community to believe that the project follows a direction with
some "head" telling people who contribute to it what they should do.

"Debian" does nothing. It has no CTO, CEO, WhateverO. The project is a
collection of hundreds of individuals who give their time to some
parts of the distro. Some do packaging, some others do documentation,
translation, infrastructure system adminitration or whatever else.

But nobody tells us what we should do. One very minor part of my
Debian tasks is being part of the pkg-running project and maintain
sports-related software. But nobody can and will tell me that I
"should" or "must" do this or that, including dropping a package I maintain.

You asked *to the maintainers of the subsurface package* to stop
distributing so-called "outdated" versions of Subsurface. You didn't
ask "Debian". If you find a way to "ask Debian" about something,
please telle me so, because after 17 years in this project, I never
found a way to do so.

I would very much see people who are not involved in the project
understand this. Because some griefs would be easier to leave behind.

Apart from that, this discussion leads to nothing : we clearly have
different views about what a distribution is and should be....and we
know for quite some time that the original author of Subsurface (at
least I learned something) also has different views.....and many
actually do not really care about that...:-)

[signature.asc (application/pgp-signature, inline)]

Message #87 received at 789875@bugs.debian.org (full text, mbox, reply):

On Wed, 2015-08-26 at 09:05 -0700, Dirk Hohndel wrote:
> Some of us have expressed our dismay with the way distributions work
> these days.
Well to be honest such dismay comes usually always from the same
fraction within open source... which is typically exactly that fraction
which tries to put more and more control over what the user does and
what he (should) want.

Quite often this fraction styles itself as the "modernists" which
allegedly bring fancy and blessed technology to opensource, like cloud.
And also quite often, what this fraction pushes for is in reality a
major step back, security wise, and especially when it comes to longer
term questions of freedom of users.

That being said, the way distributions work is still considered by many
(if not the vast majority) to be simply the way it should be.
You may not get they hype with it as when you have a fully totalitarian
ruled appstore with some fruit logo on it,... and you may not fully
expose your user's data to all kinds of criminals and agencies, as when
you put everything in the cloud or even worse run programs directly
from there - but therefore you get a system based on proven paradigms
which are amongst the main reasons why open source software is so
successful and often simply superior.

> 
> But let's get real here. We are not "hostile against core paradigms 
> of the
> FLOSS community".
Well but in fact you seem quite close to be:
- You don't want distros to use the software as they wish (like using
  an old version, or properly using the system libs (as nearly all
  other projects manage to do)) so you even openly say that you work
  against distros shipping it.
  Doesn't sound quite friendly towards the community, does it? And
  even if you'd now argue again "well distros are conceptually broken
  and thus they're not the 'community' we wish - it still limits the
  freedom of users, cause shipping a program properly as part of a
  distro, even if upstream doesn't want that to happen, is still part
  of that freedom.
  Of course you can always argue like "People can just fork" or "the 
  license still allows it", but that's merely a sticker of "we're
  free/open then", not real freedom/openness and thus it's quite
  obvious hostility against core paradigms.
  As I've said before,... it's the Oracle way of OpenSource, put a OSS
  license on it, lock out the community, fully control the whole
  lifecycle of the project and regularly step on all users toes.

- You argue with the "user experience"... so basically, everyone who
  doesn't to as you define what the current experience is, should
  either stop so or for&rename.
  If all projects would behave like this, pushing their wishes trough
  regardless of other (whether majorities or minorities), we'd
  probably have millions of forks, and the whole idea of FLOSS would
  be dead.
  That's basically the GNOME/Mozilla way of open source, a la "we
  provide a product, like it as it is, if not, go away... and if we
  break with long standing and proven behaviours... either like what
  we give you go away,..."
  Well in the GNOME case many people went away ;-) which is why we
  have Cinnamon, et al.

  This kind of arguing (i.e. with the "experience" you'd need to
  protect for the sake of the users) is actually the most hostile part
  against FLOSS here.
  Below you complain that Debian shipped old versions (for which it
  has quite some reasons, i.e. the idea of stableness,... and which
  you as upstream probably provoked as well, by making subsurface more
  and more difficult to package, unless of course you're happy with 
  providing an installer blow which ships at least parts of it's ext 
  dependencies with it).
  Which version a distro ships is in most cases (there are some
  special exceptions) none of upstream's business. It's part of the
  freedoms one should get by FLOSS.
  What comes next? That one could argue "our products experience is
  destroyed if it's shipped in an non QT desktop environment"? Or "you
  must not change the maps provider e.g. to non-OSM-whatever, as it
  destroys the experience"?
  Will future versions of the binary subsurface have a internal update
  system that nags every 10 minutes to update, because they use a
  version which no longer matches the current experience?

  Arguing with the user experience sounds all to familiar to what evil
  greedy companies like MS/Apple/etc. do. Fully controlling
  everything, pushing out competitors or non-endorsed usage models...
  and all of course just "for the sake of their users".

  And yes, you're not doing this (yet),... but the way you argue is
  just that. Having the sticker of "GPL" attached to some piece of,
  code alone doesn't make it free yet - sure everyone could fork
  subsurface, but as said before this is more theory than practise.

- Shall I continue? I guess not...

> The catholic church had the crusaders, Islam has ISIS, the open 
> source
> community has their extremists. Neither of those extremist groups 
> speak
> for the whole community. You do not speak for the open source 
> community.
> I don't either. Neither do I claim to do so.
And neither did I.
Yet we all know that some things are most probably beyond the paradigms
and bad (well at least within some of those religions)...like beheading
innocent people, or running a plane into a skyscraper.
And one doesn't need to be the speaker for all to be able to realise
this and it's still true even if god (which would probably be that
Finnish PADI diver living somewhere in Oregon, in case of the kernel)
would claim so.

> I'm sorry we mislead you.
Well I haven't said it was done on purpose... :)

>  I don't quite understand how we mislead you. I
> don't quite understand how data in our open XML format is similar to
> spending money on a DLSR - but I guess we have by now well 
> established
> that we are talking past each other.
Isn't it obvious? The DSLR company changes a major part of their
systems (like you change subsurface from being reasonably
distributable), like the mount and the electrical stuff there.
I can no longer use my old but still good lenses on new camera bodies
(like I cannot use my subsurface data in future Debians).

Of course you can argue: "you have your open XML format, just convert
it to whatever you want"... but while I can easily do it, not every
user may have the necessary skills.
It's the same with the cameras and lenses,... typically you can always
find some way to mount older lenses on a newer camera,... but it's
quite some effort and you always loose something (like functionality
and/or quality).

For the camera manufacturer, the misleading part would have been their
promise that this is the new mount which is here to stay for decades to
come (ask Olympus users, they know what I'm talking about ^^)... for
subsurface it would have been the implicit assumption by common sense,
that - unless otherwise noticed - it would behave like most other sane
FLOOS project, e.g. not forking libs without renaming them... and not
actively working aginst distros shipping it.

> We have asked SPECIFICALLY Debian to stop providing an out-dated
> version
> of Subsurface to its users as that caused confusion and problems for 
> our
> users and support burdon for us.
Well I've already mentioned above that it should be none of any
upstream's business which versions a distro ships and also which
version a user has installed.
Or would your users of your binary installers get into troubles when
they don't want to update anymore?

Of course, however, you're absolutely free to deny support for outdated
versions... and point people to the distributor instead.
I thought that would be normal and every end-user would understand
this.

>  Debian was unwilling to follow our
> choices of open source components that we used.
"Unwilling" ... well if you put people obstacles in their way to follow
proper policies o.O
Plus you shouldn't forget that Debian *is* a community project, so even
if you wouldn't have that issues with your internal library forks, it
could still simply be a matter of manpower that the current version of
subsurface wasn't packaged.

>  So we asked Debian to drop
> bundling Subsurface since we provide a version of Subsurface which a 
> diver
> who happens to run Debian and wants to use Subsurface can install.
Well I guess most experts would probably discourage their users from
doing so for compatibility and security reasons.

> Here's the funny thing. There aren't a lot of options for a diver 
> looking
> for a decent open source dive log. But there are a TON of options for 
> a
> diver looking for an OS that supports her needs. And the numbers that 
> we
> have clearly show that a tiny fractions of divers seem to think that
> Debian is their best choice. And the audience for which Subsurface is
> being developed is divers, not Debian maintainers.
Well you still haven't told where/how you get your numbers from :-)

As mentioned before, non of the divers I know (except for one single
case) wouldn't even know what Linux/Debian/opensource or subsurface are
and simply use the original software for their DC.
And that single exception has some 15k of dives on his back and stopped
logging like 10 years ago ;)

> XML still is the default storage format.
Ah nice :)
Well that's basically the main reason why I joined the discussion, even
if that part fell a bit low:
Simply disabling the libgit parts may be a way for the Debian
maintainers to keep up with an at least somehow "proper" packaging of
subsurface.
libdivecomputer could be counted as a special exception that is not
separately packaged and maybe even statically linked... and the "main"
libdivecomputer isn't used anyway by something else.
So only subsurface-marble would be left as a problem maker.

>  The git backend was added in
> preparation for cloud storage of dive data, which is in return one of 
> the
> key features needed before it makes sense to have an Android 
> application.
> 
> See, we are interested in what divers would like - and a full fledged
> Android app has been very high on the list of things people ask us 
> for...
> 
> And now I would have to tell people in the Android store "seamlessly
> exchange data with Subsurface 4.5 on the desktop (except Subsurface 
> 4.5 as
> shipped by Debian)". That's ridiculous.

> Demand? I have politely asked to respect our wishes. I can't stop you 
> from
> shipping a pile of dog poop and calling it Subsurface. All I did was 
> ask.
okay then s/demand/wished/g

> If by "properly packaged" you mean "broken and incompatible with
> upstream"
> then yes, you are right.
Apart from when one would want to use the Android software and cloud
functionality of subsurface - when exactly would it be necessary to be
"compatible with upstream" (in the sense of fully up to date)?

> They are screwed because Debian maintainers insist on removing
> features
> and refuse to accept upstreams choice of libraries we want to depend 
> on.
So much for "you just wish" and "don't want to control"... o.O
But seriously... I haven't read here that anyone of the former
maintainers ultimately insisted on removing features.
Sure they weren't all to happy with broken software design (i.e.
internally forked libs) but there was that post from Salvo where he
showed up a possible way when you'd have properly renamed your forks
(yeah call it "branches" or whatever you like... effectively they're
forks in this case).
He said that "Debian, as a general rule, disallows duplicated source
packages" but that doesn't mean that there can't be exceptions if
there's good justification (even if there's no good justification -
take the former situation with ffmpeg/libav).

> They are more than welcome to use the packages that we provide - or 
> switch
> to a more sanely run distribution.
> 
> I'm talking to the Fedora maintainer right now about getting 
> Subsurface
> packaged for Fedora 23.
I'm kinda confused now... in the previously mentioned list post, you
wrote that you actively work against making packaging subsurface within
distributions, quoting:
"we'd much rather have distributions drop Subsurface"... "in a
way to intentionally prevent distributions from shipping Subsurface"
Now you say you don't and distributions are welcome, as long as they're
run "sanely"?!

So it's basically just Debian which you don't want to ship subsurface
and with RH/Fedora it seems to be possible to match their policies (and
I'm sure they also have some policies about packaging)?!
Honi soit qui mal y pense!

Or does "sanely" mean for Fedora to have questionable code duplication
and forking without renaming? Then good night poor Fedora ;-)

> Actually I talked to Jef (the libdivecomputer maintainer) about this 
> and
> we agreed that this should just be a branch of libdivecomputer, not a
> fork. The repository from which you can get our version is named 
> libdc
> instead of libdivecomputer in order to avoid confusion, but it's 
> still
> just a branch in libdc - libdc master is the same as libdivecomputer
> master. Ironically libdivecomputer is even hosted on my 
> infrastructure.
To be honest I don't get it... why not just keeping both up to date as
one with a stable API? At least if you're really as open as you claim,
because wasn't this the idea of libdivecomputer? Having a generic and
dive computer library and not just something for subsurface?

Then distros could have used their system libdivecomputer, at most at
the expense of some models not yet supported,... which, as I've
mentioned previously, is a non-issue as new dive computers don't hit
the marked weekly.

Well long discussion,... thanks for it, but I guess I've lost all
interest (aka holidays-mode: doing real dives is much better than
arguing how to log them ;) )... so I'm out.

Cheers and thanks for all the fish, crustaceans and see snails ;-)
Chris.

Acknowledgement sent to Anton Lundin <glance@acc.umu.se>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Wed, 26 Aug 2015 20:51:03 GMT) (full text, mbox, link).

Message #92 received at 789875@bugs.debian.org (full text, mbox, reply):

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

Acknowledgement sent to Mikko Rasa <tdb@tdb.fi>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Wed, 26 Aug 2015 22:45:03 GMT) (full text, mbox, link).

Message #97 received at 789875@bugs.debian.org (full text, mbox, reply):

Since these emails managed to escape my mail filters and catch my 
attention, I'll butt in with my opinion.  Apologies if this has been 
said already.

Have you considered in-source copies of the modified libraries?  Perhaps 
as git submodules?  If you take full control of building and installing 
them, you could either link them statically or install them in a private 
directory.  Just yesterday I debugged a segfault in icedove which was 
caused by the package shipping a custom version of libldap under 
/usr/lib/icedove (see [1] for details), so this kind of thing isn't even 
unprecedented in Debian.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703857

-- 
Mikko

Message #102 received at 789875@bugs.debian.org (full text, mbox, reply):

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@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@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-running-devel

Acknowledgement sent to Linus Torvalds <torvalds@linux-foundation.org>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Wed, 26 Aug 2015 23:15:08 GMT) (full text, mbox, link).

Message #107 received at 789875@bugs.debian.org (full text, mbox, reply):

On Wed, Aug 26, 2015 at 3:41 PM, Mikko Rasa <tdb@tdb.fi> wrote:
>
> Have you considered in-source copies of the modified libraries?

Ehh. That's what subsurface has done since day#1 - even back when I
maintained it (long long ago), I refused to link against a dynamic
libdivecomputer, because the libdivecomputer versioning is broken, and
it's stupid to do dynamic linking for something that isn't shared
anyway.

The Debian people were crazy, and said "that's against our rules", and
wanted a separate libdivecomputer library.

These days, subsurface does its own libgit2 and libmarble due to
similar issues. No, not using git submodules, but in the build
scripts. And again, who complains?

So quite frankly, the fact that Debian people now attack Dirk, who has
been bending over backwards over these kinds of stupidities, is not a
big surprise. I think it's in the Debian DNA to care more about rules
than about technical sanity. The whole "this is the only right way to
do licensing" thing extends to "this is the only correct waty to do
packaging".

It's sad to see.

                Linus

Information forwarded to debian-bugs-dist@lists.debian.org, Debian running development group <pkg-running-devel@lists.alioth.debian.org>:
Bug#789875; Package src:subsurface. (Thu, 27 Aug 2015 03:36:04 GMT) (full text, mbox, link).

Acknowledgement sent to Michael Gilbert <mgilbert@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Thu, 27 Aug 2015 03:36:04 GMT) (full text, mbox, link).

Message #112 received at 789875@bugs.debian.org (full text, mbox, reply):

On Wed, Aug 26, 2015 at 7:11 PM, Linus Torvalds wrote:
> So quite frankly, the fact that Debian people now attack Dirk, who has
> been bending over backwards over these kinds of stupidities, is not a
> big surprise. I think it's in the Debian DNA to care more about rules
> than about technical sanity. The whole "this is the only right way to
> do licensing" thing extends to "this is the only correct waty to do
> packaging".
>
> It's sad to see.

Perhaps it isn't clear external to the project, but participation in
the Debian BTS does not automatically make one a Debian person, which
not a defined status.

The maintainer of the subsurface package, an official Debian status,
removed the package on request, so in many ways, problem happily
solved?

As with any internet discussion forum there are those whose
contributions are a net negative, and Debian always errs on the side
of free speech over ban hammer, so unfortunately this kind of
distraction persists.

You can probably expect additional unblinking walls of text chock full
of insult and little actual technical content incoming from
scientia.net.

My advice is to not feed.

Best wishes,
Mike

Information forwarded to debian-bugs-dist@lists.debian.org, Debian running development group <pkg-running-devel@lists.alioth.debian.org>:
Bug#789875; Package src:subsurface. (Thu, 27 Aug 2015 07:09:04 GMT) (full text, mbox, link).

Acknowledgement sent to Sylvestre Ledru <sylvestre@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Thu, 27 Aug 2015 07:09:04 GMT) (full text, mbox, link).

Message #117 received at 789875@bugs.debian.org (full text, mbox, reply):

Le 27/08/2015 05:33, Michael Gilbert a écrit :
> On Wed, Aug 26, 2015 at 7:11 PM, Linus Torvalds wrote:
>> So quite frankly, the fact that Debian people now attack Dirk, who has
>> been bending over backwards over these kinds of stupidities, is not a
>> big surprise. I think it's in the Debian DNA to care more about rules
>> than about technical sanity. The whole "this is the only right way to
>> do licensing" thing extends to "this is the only correct waty to do
>> packaging".
>>
>> It's sad to see.
> Perhaps it isn't clear external to the project, but participation in
> the Debian BTS does not automatically make one a Debian person, which
> not a defined status.
>
> The maintainer of the subsurface package, an official Debian status,
> removed the package on request, so in many ways, problem happily
> solved?
>
Even if I am not the initial packager of subsurface, I was the
maintainer for the past
few years.
I think we worked great with Dirk. He uplifted some of my patches
without any issue,
always been friendly and quick to answer. He was a great upstream. We
quickly discussed
at the New Orleans during Linux Plumber about this packaging.

Now, he thinks that the way we do things in Debian is not the right way
for subsurface.
To be honest, for libraries being heavily modified, I agree with him.
Sometimes, it is necessary to ship embedded sources. It is a crazy waste
of everybody time
to try handling that.
Daily, I see that at work. Being a release manager for a major web
browser, I see a lot of hacks
being done on some libraries like Cairo or Skia. Even if they get merged
upstreams and upstreams
release a new version, the latency is too important. That does not scale
for Debian. Recently, a top crash
on fedora was caused because they were using the system cairo and not
the one shipped by upstream (
https://bugzilla.redhat.com/show_bug.cgi?id=1253086 ).
In some cases, shipping third party libraries into the upstream code is
the best way.

Sylvestre

Information forwarded to debian-bugs-dist@lists.debian.org, Debian running development group <pkg-running-devel@lists.alioth.debian.org>:
Bug#789875; Package src:subsurface. (Thu, 27 Aug 2015 13:57:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Hohndel <dirk@hohndel.org>:
Extra info received and forwarded to list. Copy sent to Debian running development group <pkg-running-devel@lists.alioth.debian.org>. (Thu, 27 Aug 2015 13:57:03 GMT) (full text, mbox, link).

Message #122 received at 789875@bugs.debian.org (full text, mbox, reply):

On Thu, Aug 27, 2015 at 09:08:03AM +0200, Sylvestre Ledru wrote:
> Le 27/08/2015 05:33, Michael Gilbert a écrit :
> > On Wed, Aug 26, 2015 at 7:11 PM, Linus Torvalds wrote:
> >> So quite frankly, the fact that Debian people now attack Dirk, who has
> >> been bending over backwards over these kinds of stupidities, is not a
> >> big surprise. I think it's in the Debian DNA to care more about rules
> >> than about technical sanity. The whole "this is the only right way to
> >> do licensing" thing extends to "this is the only correct waty to do
> >> packaging".
> >>
> >> It's sad to see.
> > Perhaps it isn't clear external to the project, but participation in
> > the Debian BTS does not automatically make one a Debian person, which
> > not a defined status.
> >
> > The maintainer of the subsurface package, an official Debian status,
> > removed the package on request, so in many ways, problem happily
> > solved?
> >
> Even if I am not the initial packager of subsurface, I was the
> maintainer for the past
> few years.
> I think we worked great with Dirk. He uplifted some of my patches
> without any issue,
> always been friendly and quick to answer. He was a great upstream. We
> quickly discussed
> at the New Orleans during Linux Plumber about this packaging.

Thanks, Sylvestre, I really appreciate you saying that.
Asking Debian to drop Subsurface wasn't an easy decision to make. But I
still believe it's the right decision at this point. Maybe in a little
while, once libgit2 has made it into Debian we can revisit the question if
a full-featured Subsurface can be shipped with Debian. Right now I think
the solution that we have is the best we can do.

Thanks for all your work on Subsurface.

/D

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 25 Sep 2015 07:40:19 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Jul 1 15:26:52 2023; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #789875 subsurface: FTBFS in experimental

Debian Bug report logs - #789875
subsurface: FTBFS in experimental