Bug#789875: subsurface: FTBFS in experimental
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#789875: subsurface: FTBFS in experimental
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
Bug#789875: subsurface: FTBFS in experimental
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 forrename. 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
Bug#789875: subsurface: FTBFS in experimental
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 opinionsand also send a mini apology for having been kinda rudeI do share Christoph's feeling about the raison d'être of distros and, well, I'm never happy when this is not well understood
Bug#789875: subsurface: FTBFS in experimental
Quoting Dirk Hohndel (d...@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 beand 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 Description: Digital signature
Bug#789875: subsurface: FTBFS in experimental
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
Bug#789875: subsurface: FTBFS in experimental
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
Bug#789875: [Pkg-running-devel] Bug#789875: subsurface: FTBFS in experimental
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 gla...@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
Bug#789875: subsurface: FTBFS in experimental
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
Bug#789875: subsurface: FTBFS in experimental
On 26 August 2015 at 05:38, Christoph Anton Mitterer cales...@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 --
Bug#789875: subsurface: FTBFS in experimental
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 ;-)
Bug#789875: subsurface: FTBFS in experimental
On Wed, Aug 26, 2015 at 3:41 PM, Mikko Rasa t...@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
Bug#789875: subsurface: FTBFS in experimental
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
Bug#789875: subsurface: FTBFS in experimental
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
Bug#789875: subsurface: FTBFS in experimental
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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
