Hi again :)
>To be fair, while this will fix the issue for a while, we shouldn't >attach a sense of eternity to this resolution. :) At some point, 1.0 >will stop being supported in borg, and stretch will stop being supported >in Debian. If anyone here is still running lenny boxes, you know what I >am talking about. well, "forever" in computer science is somewhat located in the meaning of "a release or two" :p not a problem, there is google for common-known problems, and in case I'll complain about giving users an upgrade path :D >autoconf suite does exactly that: the Debian archive has automake1.5, >automake1.6 and so one. It uses the alternatives system to support >multiple installs in parallel. That is annoying, but it works. sure, but I would like to avoid that if possible >that backport is now out of date, btw. :) explained why it is outdated in the other email >prior to backporting, sure, but i'm talking about opening a bug report>for the >backport, where we can track stuff exactly *like* that. thanks, being lazy is not an excuse to me (I use irc for asking stuff and sometimes things gets just lost/unread) >so if you don't mind, i'll create that backporting issue and make it >depend on the msgpack backport. :p I asked exactly this before reading this email lol :) >i'll be happy to do those backports>myself. of course if zigo is taking care >of it, i won't step on his >toes, but it is common practice for the backporter to be a different >person than the package maintainer... me too, but zigo wants to backport all the openstack in a row, and I don't want to make troubles to him, specially because when he promised this he backported all the openstack in less than a week (and for some obscure reasons msgpack backport got rejected/missed, but I remember I saw it on backports-new queue) >honestly, that is Ubuntu's problem, not ours. and while our decisions do >affect Ubuntu, they profit from our packaging work for free, so they can >hardly complain about things being out of sync on that other side. they >are the ones who are responsible to do those syncs, not us. and yes, if >we fix those issues in Debian (e.g. through backports), that *will* >provide a clear path for derivatives as well. actually I don't talk about Ubuntu (I became Ubuntu Developer less than a week ago, so I'll take care there too). The problem are the more obscure Debian/Ubuntu based distros (and there are really too many). The quality of their software might decrease just because we upload stuff that breaks without caring about them. >meh. let's say it's a "debian family problem" and leave it at that if >you want. :p yes, I don't like to break derivatives for no good reason. >but i don't think the debian borg maintainers should take the fall for >the 6 month rolling schedule of Ubuntu. that would be totally >unfair. xenial will be a snapshot of debian testing/unstable, as any >other ubuntu release. if Ubuntu people do not want borg 0.29, they can >remove it on their end... sure, that is true, but I like to have (under my umbrella), testing packages that if Debian has to be released tomorrow, they will just be suitable. (I don't want to wait for a freeze to fix my RC bugs, specially because I leave RC buggy packages to Ubuntu and everybody that runs testing) the whole point was: please don't make holy wars about Debian or Ubuntu, and try to use common sense where possible, just simple as is :) >sure. i just happened to look at backporting borg and figured it would >be nonsensical if borg was removed from testing before that. :p true story >sure, thanks for that! thanks to you, you have been *really* helpful, since the wnpp bug. And honestly I packaged it just because of the "borg" name :) Cheeers! LocutusOfBorg
