Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*
Excerpts from Otto Kekäläinen's message of 2016-07-03 12:46:29 +0100: > > 3. libmysqlclient.so.18 > > Here theres's no concensus yet within the pkg-mysql-maint team on this one. > And IMO, there won't be one until MariaDB accepts that they've created a forked library that is API-incompatible with libmysqlclient. > I suggest we extend the mysql-defaults source package to provide a > real default-mysqlclient-dev metapackage, which other packages can > build depend on, using versions if needed (just as default-jdk does). > > Current mariadb-10.0 source package does not ship any > libmariadbclient18 nor libmariadbclient-dev packages at all, as > previously it was seen as against the policy (but mariadb-5.5 in > Debian did). I suggest we start producing them now again to make a > libmysqlclient.so(.18) available from mariadb-10.0. > > Having two libmysqlclient.so.18 files from two different packages is a > controversial topic. They are not identical so it is ugly to use the > same name. This is however a necessity dictated by the need to provide > a drop-in-replacement that can be used directly without going into > every single clienting program and editing the C headers and soname > calls. > It's _extremely_ ugly to use this name. MariaDB needs to stop shipping a library that claims to be libmysqlclient, but is not. This notion of a drop-in replacement is just a bait-and-switch tactic (even if it isn't meant to be one). By allowing somebody to build against a new API without changing their build scripts, it's just allowing them to accidentally use that new API and then unknowingly be dependent on symbols only available in the forked library. There's a different between ABI equality, and ABI compatibility, and IMO, the former is more important for Debian. > It should be noted that the Debian packages shipped directly from > mariadb.org have provided the libmysqlclient.so file since forever and > there has not been problems and the drop-in-replacement function has > been fullfilled as expected. All packages that used to depend on > Oracle MySQL client library have continued to function with the > MariaDB equivalent when mariadb.org repositories are activated. > There have not been problems that users reported to MariaDB, because the issue is extremely subtle and subversive. Those users would only ever know that there was a problem if they wanted to distribute their code and had another user try to build on libmysqlclient. For the average MariaDB user, that's not such a big deal, as they may not be distributing their code. For Debian, we're distributing all of it, and we have a duty to give users reliable software. We don't want to build against libmariadbclient-dev-compat and then the software just doesn't work with libmysqlclient.so.18 from MySQL. > It should also be noted that the soname version number 18 has been > used in Oracle MySQL for a long time without bumping it despite > changes in the API. The API changes have also gone undocumented all > the time as the libmysqlclient18 package does not have .symbols file. > Oracle has finally bumped the soname version to 20 in MySQL 5.7. The > number 19 is not used anywhere, but was left as something that can be > resorted to in 5.6, in case somebody would complain too much that 5.5 > and 5.6 API differ but have same version number. No one has, so for > all practical purposes, the current situation is OK. > The past was horrible, and MySQL obviously did weird things and our packages were not sufficient to police this properly. But that doesn't change the fact that MariaDB has hijacked the mysqlcient soname. > The solution I suggest works nicely in the scope of > libmysqlclient18/libmariadbclient18 and is resilent for scenarios > where libmysqlclient20 is introduced or where even more client > libraries are available (mainly libmariadb2), but I won't go into the > details of those now, as I think here is enough information to decide > on whether or not it is OK to provide libmysqlclient.so from a > libmariadbclient18 package. This would also mean we introduce the > default-libmysqlclient-dev pmetaackage which depends on either > libmariadbclient-dev or libmysqlclient-dev package. > > Please comment and advice on how to proceed with packaging to satisfy > with the switchable defaults requirement. > IMO, it's only OK for MariaDB to provide libmysqlclient.so if it is 100% equivalent to MySQL's libmysqlclient.so. If there are extra API calls, and extra symbols, it's not the same, and it won't produce a compatible program linked to libmysqlclient.so.18.
Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB
Excerpts from Steven Chamberlain's message of 2016-01-27 12:30:09 -0800: > I'll try to make this my last intervention in this thread. Because > it's not my decision, or area of responsibility, and I likely won't be > one of the people having to do the work when a decision is made, but... > I appreciate your words very much Steven. > Clint Byrum wrote: > > most of these CVE's would remain fully undisclosed and unfixed in both > > MySQL and MariaDB if the MySQL engineering team or customers had not > > found them. > > Sorry, this is not compelling. As long as Oracle sells MySQL to > enterprise, it *must* do these things, and release source code to > satisfy legal obligations of what is a GPL codebase. It is really only > doing the bare minimum in that regard. It was also a condition of > Oracle's acquisition of MySQL AB: > > "As part of the negotiations with the European Commission, Oracle > committed that MySQL server will continue until at least 2015 to use the > dual-licensing strategy long used by MySQL AB, with proprietary and GPL > versions available" > according to > https://en.wikipedia.org/wiki/MySQL#Legal_disputes_and_acquisitions > > Oracle may still drop MySQL support like a hat due to market conditions, > regardless of whether Debian has already shipped it by then. > The code dump is definitely a condition, but it turns out that's also prevented an actual fork of their work from forming. MariaDB does pull things in, but it's forked so far now that there's still enough compelling reason to run Oracle's code-dumped version that people choose to do it every day. > And apart from sponsoring Debian packaging work, Oracle seems > conspicuously missing from: > http://debconf16.debconf.org/sponsors.html > http://debconf15.debconf.org/ > https://www.debian.org/mirror/sponsors > https://www.freexian.com/en/services/debian-lts.html > I think this unfairly characterizes them as free riders when the point we've been trying to make is that they're not free riding, but just choosing to contribute with engineering time. > Clint Byrum wrote: > > [...] if it were written down somewhere as an actual policy. [...] > > Norvald H. Ryeng wrote: > > Tell us exactly what you want, in detail. If you don't then I don't > > think your position is reasonable. > > Robie Basak wrote: > > So please: the security team needs to engage directly with Oracle by > > responding to Norvald's email and enumerating exactly what is wrong. > > I don't see that Debian has to do that, at all. Other upstream projects > seem to 'just get it', so Oracle management is really expecting special > treatment. IMHO I respond to bad dealings with a company by shopping > elsewhere, not helping them improve their business practices. > Of course Debian doesn't have to do it. However, here you have a corporate citizen who _wants_ to contribute, and they're being told to buzz off. When asking why, they're getting derisive "if you have to ask you'll never know" type of treatment. Just because we don't like them, doesn't mean we can kick them out of our club. > This is perhaps more significant than a mere decision over what goes > into the next release. I see a really fantastic, rare opportunity for > Debian to take a moral stand against Oracle for shameful mistreatment > of free software to date. rock on \m/ > So basically "they're bad people by my own conjecture, so let's stick it to them". I am sorry, but I thought Debian would welcome those who follow our rules. > Niels Thykier wrote: > > I appreciate that the release team failed on action item several > > months back and have not been very proactive in the communication. > > And I am sorry that it has (and probably will) inconvenience you and > > MySQL upstream. > > I do have personal sympathy for Debian contributors who became entwined, > by their career choices, with the business preferences of Oracle and > Canonical. And the team of MySQL developers who must work under > Oracle's non-disclosure policies. But I don't think it should get in > the way of doing whatever seems right for Debian's users and by its > own principles. > This is a very broad statement, and I suggest you add _specifics_ to any accusations that somehow having MySQL in the archive is bad for Debian's principles. Which principles are not being upheld? The users are getting well maintained Free software. The fact that it's being done a way that we all think is silly (and make no mistake, I think it is one of the silliest things I've ever seen in open source software) isn't a valid reason to reject it. It just feels good to say. If you want to kick them out, by all means, do it. But have an actual reason please.
Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB
Excerpts from Holger Levsen's message of 2016-01-26 02:45:32 -0800: > Hi, > > On Dienstag, 26. Januar 2016, Clint Byrum wrote: > > However, I have confidence that our friends in the MySQL engineering > > team can frame the loss of the last foothold for MySQL in Linux distros > > as a direct path toward _less_ money for Oracle. > > why do you think so? I mean, doesn't less Mysql mean more OracleDB, thus > *more* money for Oracle? ;) > > (I'm not saying that's the case either, I was merely explaining why I'm > surprised abour your confidence.) > I'm not so confident it will be _enough_ money to change the security policy. However, I am confident that a decision has already been made to support Debian and Ubuntu continuing to ship MySQL. There is direct evidence of it in the form of Oracle engineers directly contributing to the packaging effort. I won't speculate too much on why they believe this, but I imagine one reason is simple: If Ubuntu and Debian don't have them, it will make them harder to find, and might push people to select PostgreSQL, or "anything else that isn't in the distro" when making choices. > > So if we can just be > > patient with them, and actually facilitate their participation in this > > grand community of Debian, it's possible that a compromise can be found. > > Oracle bought Sun in 2010, so personally I don't see how we should be more > patient, especially because… the following aint anything new nor special… > Have you ever seen how slowly things change in large corporations? I know it's hard to believe this, but even _Debian_ moves slowly sometimes. https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-February/013196.html That is the first we talked about removing MySQL for these problems. Oracle responded directly and has remained engaged since then. That they haven't changed everything is largely a function of us not being extremely focused in what we're asking for. > > Meanwhile, I'd like to challenge someone to point to the exact requirement > > from any official source affiliated with Debian as to what constitutes > > an acceptable level of disclosure for a package to remain in the archive. > > sigh. > > go to https://security-tracker.debian.org/tracker/source-package/mysql-5.5 > and > count occurances of the string "Unspecified vulnerability", if you do this > with iceweasel it will not even tell you the exact number of matches, just > "over 100". > > Now go to > https://security-tracker.debian.org/tracker/source-package/mysql-5.6 > and do the same. The count is at 66 here, but the counter only started 2015. > > So, once again: the exact requirement to be considered is: publish specific > information about specific vulnerabilities. Provide meaningful patches for > each specific issue. > > Don't release updates with 23 or 42 fixes bundled together with basically no > explainations whatsoever. > > And/but this is nothing new and it's very very tiring having to explain this, > again and again and still in 2016. It's not like we havent discussed this in > 2014, 2013, 2012 and probably also 2011 and 2010. > Holger, I very much value your opinions, and I _hope_ for the same things from any open source software project. However, you wouldn't have to explain it if it were written down somewhere as an actual policy. If it is, please point us to that, so we can point Oracle to it, and provide them with an ultimatum.
Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB
Excerpts from Holger Levsen's message of 2016-01-25 17:04:57 -0800: > Hi, > > On Dienstag, 26. Januar 2016, Steven Chamberlain wrote: > [...other valid points not quoted here…] > > Assuming MariaDB is affected by the same issues, I may not be in a > > technically better situation if I switched to using that. (Although, it > > seems one of the recent CVEs did not affect MariaDB?). But I look at > > their public bug dashboard as a model of how open I want development to > > happen, and it makes me _feel_ more comfortable and optimistic in that > > project already. > > Steven, thanks for wording this (all of it, also the non quoted parts) much > better than I care to do. As I said on IRC on #debian-release: > > * | h01ger is tempted to reply "tl;dr; - mysql is the db with the NDA from > oracle, mariadb is the free fork shipped everywhere - without NDAs and > without > a history of screwing free software, so let's EOT here" to the recent mail in > that thread… > > - I know this is somewhat too simplefied, eg I do acknowledge and hope that > Oracle can do better than "screwing free software", but… *they* need to show > this *by themselves*. > Yet when I read this in Robie's mail: "It is not reasonable for S to expect > U[MySQL] to change their policy in order to meet a goal if S refuse to > tell U[MySQL] how success against that goal will be measured." I have little > hope + motivation to explain this better - CVE is a public database. > > So, another summary: there's a software from a company with NDAs (which have > been applied to the question at hand, no less) and "a history of screwing > free > software" and there's a project to reuse the same codebase (and then build on > it) to not do that. > > Also, I wonder why https://en.wikipedia.org/wiki/MariaDB#Prominent_users … ;-) > Holger, I understand this frustration entirely. But let's be completely honest here. Nobody has told Oracle exactly what Debian wants. I know, it seems like it should be obvious, but for Oracle, they speak money _first_, and then software. I know, also, that this is anathema to many users, and this alone is enough to drive some to want to have nothing to do with MySQL. _I get that_. MariaDB is right over here, and I invite those of you who feel this way to switch to that fine fork of MySQL. However, I have confidence that our friends in the MySQL engineering team can frame the loss of the last foothold for MySQL in Linux distros as a direct path toward _less_ money for Oracle. So if we can just be patient with them, and actually facilitate their participation in this grand community of Debian, it's possible that a compromise can be found. Meanwhile, I'd like to challenge someone to point to the exact requirement from any official source affiliated with Debian as to what constitutes an acceptable level of disclosure for a package to remain in the archive.
Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB
Excerpts from Steven Chamberlain's message of 2016-01-25 16:48:23 -0800: > Hi, > > As a mere user (systems administrator), I'll share some questions / > criticisms from my perspective that might help shed some light on the > underlying issues. > > I was wondering why after the 2016-01-19 announcement, there is still no > patched mysql-5.5 in jessie or wheezy; and also why mariadb was only > just patched today. Debian is typically much faster than this at > getting out patches. Is it to do with complexity, available manpower, > or other things? > > Another concern I have is that when I check Debian's Security Tracker, I > although I can see which CVEs apply to my (still unpatched) systems, the > only descriptions I have are for example: > "[...] allows remote authenticated users to affect integrity via unknown > vectors related to encryption" > > That is definitely not okay in a free, open-source software project. I > want to be able to evaluate how/whether my specific configuration is > vulnerable and assess the risk for myself, while I wait for patches to > come, and decide if I even want to apply them at all. > > Why is it that way? It reflects badly on Oracle that they don't or > can't do better, and it reduces my personal trust in them. > (It's in the Debian Social Contract, "we will not hide problems"). > > In contrast, for something as complex as the Linux kernel, I'm usually > pointed to a specific Git commit showing how and where the bug was > fixed, and there's often public discussion of the vulnerability in Red > Hat's bug tracker or other sources. > > Assuming MariaDB is affected by the same issues, I may not be in a > technically better situation if I switched to using that. (Although, it > seems one of the recent CVEs did not affect MariaDB?). But I look at > their public bug dashboard as a model of how open I want development to > happen, and it makes me _feel_ more comfortable and optimistic in that > project already. > Hi Steven. Thanks very much for your participation in this discussion. One of the nuances that gets missed in these undisclosed, vague vulnerability messages, is that most of these CVE's would remain fully undisclosed and unfixed in both MySQL and MariaDB if the MySQL engineering team or customers had not found them. Does this excuse Oracle for their misguided policy of non-disclosure? Absolutely not. But I want to make it clear that we wouldn't even know about these vulnerabilities were it not for them. So which is worse: knowing that you might be broken, or not knowing at all. Regarding the speed of patching: MySQL is massive. It takes several hours to build and fully test on a good quality machine. Because the patched version came out before the CVE's and CPU's attached to it, some of this was already done. But a final set of binaries must be prepared, tested, and uploaded. I think it is understandable that this might take more than 5 days. But it should be completed soon.
Re: [debian-mysql] Request for release team decision on MySQL and MariaDB [was: Re: Bug#793316: Bug#793316: transition: mysql-5.6]
Excerpts from Moritz Mühlenhoff's message of 2016-01-14 13:11:22 -0800: > On Mon, Jan 11, 2016 at 08:14:06PM +, Robie Basak wrote: > > On Mon, Jan 11, 2016 at 07:27:30PM +0100, Moritz Mühlenhoff wrote: > > > *Sigh*. And that is exactly the problem (and we've already pointed this > > > out at DebConf half a year ago) > > > > > > We should really go ahead and move forward, the freeze isn't terribly far > > > away. > > > > I don't think it's reasonable to use a security question raised by > > MariaDB as an excuse to kick out MySQL. Because whether you do so or > > not, your situation with getting information about CVEs in relation to > > MariaDB will not change. > > > > Let's treat the situation with each on their own merits and be > > constructive about this. > > This policy equally hurts us for mysql alone. Debian LTS had go through > a messy 5.1-5.5 transition because of Oracle's policies. > That's a real shame. That said, I think that is a one-time fallout from the fact that 5.5 was _really_ late getting into Debian, and basically missed a release because nobody was working on MySQL for a while. Still, it's worth noting that the ridiculous "no disclosure" policy puts users in the awkward position of either being forced down the path to newer releases, or accepting that they just know _that there is a problem_, and not _what the problem is_. > > That *is* something that might be able to be addressed directly by > > Oracle, and if it does get addressed then MariaDB's situation could > > improve too, and Debian wins. > > We've already raised this at DebConf with Norvald from Oracle half a year > ago and nothing happened. Several other parties didn't get these infos > from Oracle in the past (not even Red Hat). The VirtualBox developers > were equally shut down by Oracle (after being cooperative for a while). > > I see no chance that this will really happen. We'll definitely not > wait for it and we need to make a move ASAP. The freeze is only like > eight months away and a transition from mysql to mariadb takes it's > time. > To be clear, it is not a transition from mysql to mariadb. MariaDB is there, and available, and users may use it as they please. The suggestion is that because it is there, we can discontinue inclusion of MySQL. > > So please: the security team needs to engage directly with Oracle by > > responding to Norvald's email and enumerating exactly what is wrong. > > Otherwise nobody can reasonably claim about what Oracle is not doing in > > relation to security, because the security team refuses to say what the > > problem is. > > *sigh* That as already been raised multiple times and it was all reported > to Oracle at DebConf. Information about specific security issues and > their mapping to fixes (just like raised by Otto, which explains the > need very well) need to be publicly available (we're unable and unwilling > to sign an NDA). > Full disclosure will not happen, and we shouldn't expect it to. If that is actually a requirement for inclusion in Debian, then MySQL should be dropped immediately and a transition to using MariaDB for libmysqlclient should be started in place of the 5.6 transition. But, my understanding was that it was _not_ required, and that the point release shipping has gone relatively well, aside from the fact that the security team has been uploading the updates (we need to fix the communication channel there, but I think that's under way).
Bug#804810: RM: python-repoze.what/1.0.9-5
Excerpts from Emilio Pozuelo Monfort's message of 2015-11-12 01:18:55 -0800: > On 11/11/15 23:32, Clint Byrum wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: rm > > > > This package is blocking python-repoze.who 2.2-2 from entering testing. > > That, in turn, blocks python-pysaml2 v3 from entering testing, which is > > in turn blocking keystone from entering testing. > > > > Meanwhile, the project upstream has not received any commits for several > > years. The only real reverse dependency in the archive, turbogears2 > > will hopefully remove the dependency on python-repoze.what-plugins given > > this bug: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804809 > > > > tg.devtools is already removed from testing and so would not block this. > > > > So, once that bug is acted upon, it should be quite simple to > > remove this and python-repoze.what-plugins from testing (and likely > > eventually from the archive if they are not updated to work with modern > > python-repoze.who). > > Please ping us once that bug is fixed. Hi Emilio, thanks for the quick response. Laszlo fixed 804809 just now, so once python-turbogears2 2.3.7-1 migrates to testing, I believe that means python-repoze.what and python-repoze.what-plugins can be removed from testing. Please let me know if there is anything else I can do to help.
Bug#804810: RM: python-repoze.what/1.0.9-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm This package is blocking python-repoze.who 2.2-2 from entering testing. That, in turn, blocks python-pysaml2 v3 from entering testing, which is in turn blocking keystone from entering testing. Meanwhile, the project upstream has not received any commits for several years. The only real reverse dependency in the archive, turbogears2 will hopefully remove the dependency on python-repoze.what-plugins given this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804809 tg.devtools is already removed from testing and so would not block this. So, once that bug is acted upon, it should be quite simple to remove this and python-repoze.what-plugins from testing (and likely eventually from the archive if they are not updated to work with modern python-repoze.who).
Bug#793316: [debian-mysql] Bug#793316: transition: mysql-5.6
Excerpts from Vincent Bernat's message of 2015-07-25 05:28:15 -0700: ❦ 23 juillet 2015 07:17 -0700, Clint Byrum spam...@debian.org : I'd be interested to hear the security team's impressions on how shipping micro releases of MySQL has gone for them. They've been doing most if not all of the work, and I haven't seen bug reports flying in about those updates, so I suspect our primary gripe about MySQL may actually be no big deal. Sure they have a _ridiculous_ policy about not telling us what the actual security problems were. But they also have quite impressive policies on not breaking things in micro releases. One minor gripe about that: MySQL doesn't provide a stable ABI across those micro releases for external engines. So, any external engine has to be recompiled. I have the problem with pinba-engine-mysql and didn't want to make the way to stable with the problem unaddressed. I've asked the release team for guidance [1] but didn't get an answer. I understand that there are more serious matters to address. Agreed, this is one of those why don't they just do that? situations. I tried to package HandlerSocket and have given up for similar reasons. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1437865499-sup-8...@fewbar.com
Bug#793316: [debian-mysql] Bug#793316: Bug#793316: transition: mysql-5.6
Excerpts from Paul Wise's message of 2015-07-23 21:09:13 -0700: On Fri, Jul 24, 2015 at 5:06 AM, Otto Kekäläinen wrote: The wish of the release team and security team has been to keep just one MySQL variant. If such a decision is made, it must be made above the pkg-mysql-maint team as the team will never be able to agree which favourite is the best one. After Clint's MySQL 5.7 advertisement I am tempted to present what I like feature wise in MariaDB (in current and upcoming versions), but let's not start such an discussion, as this is not the time or place for such a contest. Let's just be happy that we have Free Software based options and competition that drives innovation forward for everybody. Stupid question on behalf of a lurker: what would it take for Oracle MySQL, MariaDB, Percona and any other MySQL forks to be merged into one upstream project? An act of god? The orgs running the projects simply have different goals, and the architecture doesn't lend itself to an apache-style just make a mod to make it do what you want community. Drizzle was an attempt to modularize MySQL, but it fizzled out when corporate sponsorship dried up. I _could_ see MariaDB merging most of the patches in the Percona variants (many have already been merged), but Percona would likely still want to run its own fork to be able to address their customers' service needs in an open-source platform. If Oracle didn't have a private bug tracker, or their weird policies, Percona might also be able to just work in-tree for MySQL, but that's just not going to happen. :-P It's a tangled web, so there's no really obvious answer to all of this. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1437723275-sup-3...@fewbar.com
Bug#793316: [debian-mysql] Bug#793316: transition: mysql-5.6
Excerpts from Emilio Pozuelo Monfort's message of 2015-07-23 01:59:15 -0700: On 22/07/15 21:24, Andreas Beckmann wrote: Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal X-Debbugs-Cc: pkg-mysql-ma...@lists.alioth.debian.org Control: block -1 with 793314 793315 On behalf of the MySQL maintainers I'm filing this transition bug. Please keep the list Cc:ed on replies. The core packages involved here are mysql-5.5, mysql-5.6, mariadb-10.0. In order for mysql-5.6 to enter testing mysql-5.5 has to leave and mariadb-10.0 has to migrate at the same time. Didn't we agree that we would release Stretch with only mariadb? When do you plan to start working on that so we can drop mysql-* from testing? Please do read up on the differences. MySQL 5.6 and MariaDB 10.0 are already a little bit incompatible, but 5.7 will introduce some features that MariaDB will likely be chasing for some time. https://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html Thus far I think the main feature of MariaDB is it's not made by Oracle. However, frankly, Oracle have been helping maintain MySQL more than MontyProgram/SkySQL (easy to be above 0) and have demonstrated that they are in fact very interested in doing what is needed to keep MySQL in Debian. Otto K., a MariaDB community member, has done an amazing job at improving MariaDB and keeping it in some ways ahead of the MySQL packaging, so I think the two databases are neck and neck at this point. I'd be interested to hear the security team's impressions on how shipping micro releases of MySQL has gone for them. They've been doing most if not all of the work, and I haven't seen bug reports flying in about those updates, so I suspect our primary gripe about MySQL may actually be no big deal. Sure they have a _ridiculous_ policy about not telling us what the actual security problems were. But they also have quite impressive policies on not breaking things in micro releases. So, shipping two, or three, is a drain on resources, but there seem to be enough developers to commit to maintaining both. Perhaps we should just keep shipping both. Also sorry Percona, I've lost track of you, your Galera work is vital to OpenStack, so I hope you'll keep maintaining things as well. In the past you were right there with Oracle supporting your fork. :) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1437660426-sup-6...@fewbar.com
Bug#768930: unblock: pynag and syslog-nagios-bridge
Excerpts from Daniel Pocock's message of 2014-11-14 04:01:10 -0800: On 14/11/14 12:33, Julien Cristau wrote: On Tue, Nov 11, 2014 at 22:05:49 +0100, Niels Thykier wrote: On 2014-11-11 19:24, Clint Byrum wrote: Excerpts from Daniel Pocock's message of 2014-11-11 00:59:36 -0800: On 11/11/14 06:05, Clint Byrum wrote: [...] I think we should unblock 0.9.1. Release team have been a bit reluctant to unblock whole new versions without any justification at all In this case though, maybe they can accept that there was a good reason why it wasn't in testing before the freeze: [...] The upload only missed being in testing by 3 days, and fixes a number of issues. We don't want to ship with an old API. Seems like an easy unblock this early in the freeze. Honestly, no - the arguments present are really not all that interesting. In fact, they are a-dime-a-dozen right now. In particular, my argument for rejecting pynag/0.9.1 is that the diff is simply too large to reasonably comprehend. I've added rm hints for both packages. Hi Julien, I had offered to NMU the fix against pynag 0.8.9 and was just waiting for Clint to respond to that Apologies for not realizing thats what you were proposing. I would prefer that we ship the latest upstream, but I'm not going to fight for that. Please NMU if that will address the problem. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415973054-sup-...@fewbar.com
Bug#768930: unblock: pynag and syslog-nagios-bridge
Excerpts from Daniel Pocock's message of 2014-11-11 00:59:36 -0800: On 11/11/14 06:05, Clint Byrum wrote: Excerpts from Daniel Pocock's message of 2014-11-10 12:19:19 -0800: On 10/11/14 20:56, Niels Thykier wrote: Control: tags -1 moreinfo On Mon, 10 Nov 2014 10:31:03 +0100 Daniel Pocock dan...@pocock.pro wrote: Package: release.debian.org syslog-nagios-bridge requires pynag 0.9.1+, older versions have a bug in check result file generation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768928 I added a constraint in syslog-nagios-bridge well before the freeze so it would not propagate to testing until pynag 0.9.1 was uploaded: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763378 Note that the pynag upload in unstable is also cleaning out minified jquery and other things that make the package more compliant with Debian policy [...] Hi, I am afraid I will have to reject this request in its current form. The changes to pynag is beyond what can be reasonably reviewed and indeed it is not a targeted fix for #768928. The changes to syslog-nagios-bridge are reasonable and I could accept them, but I understand it is of no use without pynag as well. Can you please provide a targeted fix for pynag? This (just a few lines) could be dropped into debian/patches/checkresult_fix.patch https://github.com/pynag/pynag/commit/3aad1176bca4b2f39c2c851396d30647efbf2bed Clint, would you be happy to upload 0.8.9 with that or would you like me to NMU perhaps? Or is there any reason why the whole 0.9.1 should be considered for jessie? I think we should unblock 0.9.1. Release team have been a bit reluctant to unblock whole new versions without any justification at all In this case though, maybe they can accept that there was a good reason why it wasn't in testing before the freeze: a) 0.9.1 was tagged 5 August b) I sent a private email to Palli on 14 August about the bug and uploading 0.9.1 c) sent follow up and commented on the bug tracker 29 September https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763378#10 d) noticed Palli's email bouncing on 3 November, you then made the upload immediately, also removing some jquery artifacts to make it more dfsg compliant e) syslog-nagios-bridge is the only dependent package that I know of and I have been testing that against pynag v0.9.1 locally. Do you know of any other packages using pynag as a dependency? It appears that a range of issues were fixed upstream in 0.9.0 and 0.9.1 - do you know if any of these issues justify an unblock for 0.9.1 or maybe the collection of all these issues together justifies an unblock? https://github.com/pynag/pynag/issues?q=is%3Aissue+is%3Aclosed The upload only missed being in testing by 3 days, and fixes a number of issues. We don't want to ship with an old API. Seems like an easy unblock this early in the freeze. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415730114-sup-2...@fewbar.com
Bug#768930: unblock: pynag and syslog-nagios-bridge
Excerpts from Niels Thykier's message of 2014-11-11 13:05:49 -0800: On 2014-11-11 19:24, Clint Byrum wrote: Excerpts from Daniel Pocock's message of 2014-11-11 00:59:36 -0800: On 11/11/14 06:05, Clint Byrum wrote: [...] I think we should unblock 0.9.1. Release team have been a bit reluctant to unblock whole new versions without any justification at all In this case though, maybe they can accept that there was a good reason why it wasn't in testing before the freeze: [...] The upload only missed being in testing by 3 days, and fixes a number of issues. We don't want to ship with an old API. Seems like an easy unblock this early in the freeze. Honestly, no - the arguments present are really not all that interesting. In fact, they are a-dime-a-dozen right now. In particular, my argument for rejecting pynag/0.9.1 is that the diff is simply too large to reasonably comprehend. Who exactly are we affecting negatively by unblocking this package? Because we're going to waste a number of pynag users' time by not unblocking it and witholding the fixes and new features, as well as wasting the syslog-nagios-bridge maintainers' time by requiring them to backport to the old API, so I want to understand the reason we want to do that. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415740471-sup-1...@fewbar.com
Bug#768930: unblock: pynag and syslog-nagios-bridge
Excerpts from Daniel Pocock's message of 2014-11-10 12:19:19 -0800: On 10/11/14 20:56, Niels Thykier wrote: Control: tags -1 moreinfo On Mon, 10 Nov 2014 10:31:03 +0100 Daniel Pocock dan...@pocock.pro wrote: Package: release.debian.org syslog-nagios-bridge requires pynag 0.9.1+, older versions have a bug in check result file generation: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768928 I added a constraint in syslog-nagios-bridge well before the freeze so it would not propagate to testing until pynag 0.9.1 was uploaded: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763378 Note that the pynag upload in unstable is also cleaning out minified jquery and other things that make the package more compliant with Debian policy [...] Hi, I am afraid I will have to reject this request in its current form. The changes to pynag is beyond what can be reasonably reviewed and indeed it is not a targeted fix for #768928. The changes to syslog-nagios-bridge are reasonable and I could accept them, but I understand it is of no use without pynag as well. Can you please provide a targeted fix for pynag? This (just a few lines) could be dropped into debian/patches/checkresult_fix.patch https://github.com/pynag/pynag/commit/3aad1176bca4b2f39c2c851396d30647efbf2bed Clint, would you be happy to upload 0.8.9 with that or would you like me to NMU perhaps? Or is there any reason why the whole 0.9.1 should be considered for jessie? I think we should unblock 0.9.1. signature.asc Description: PGP signature
Re: [debian-mysql] MySQL in Jessie
Excerpts from Emilio Pozuelo Monfort's message of 2014-10-01 08:01:46 -0700: [ Fixing the team@security.d.o Cc ] On 26/09/14 11:31, James Page wrote: Hi Jonathan On 26/08/14 00:46, Jonathan Wiltshire wrote: Currently Jessie has version 5.5, and we would anticipate you shipping 5.6. Only experimental has seen an upload of 5.6. What's your plan here? Given the situation with upstream's approach to security releases, the security team are also in CC in case they have an opinion. We'd ideally like a situation where we only ship one fork of the codebase, so let's get your plans and take it from there. As I emailed before, the plan was to get mysql-5.6 into unstable prior to freeze; however we hit a snag that needed investigation upstream which has delayed things a bit; specifically an ABI enum change - Norvald from Oracle has done some in-depth investigate into this problem: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007040.html The break is a minor one and only impacts three in-archive packages that would need a no-change rebuild post upload of mysql-5.6; so that we don't end up with a crazy Debian specific version of libmysqlclient, the recommendation is that we don't undertake a full transition but deal with the three exceptions as a one off, and resolve the soname version bump with mysql-5.7 in the future. I'm not 100% comfortable with this but it appears to be the best compromise we can come up with. If the release team is OK with this, we'll go ahead and upload mysql-5.6 to unstable and raise bugs for the three impacted packages. Please can you confirm. I think it's rather late for such an upload, especially when it involves an ABI break. I asked other RT members and the answer I got also was that it was too late for this. So I'd say we stay at 5.5 for Jessie. Robie and I are also working with Percona on PXC 5.6 (and PS 5.6); that might not land in time so percona-xtradb-cluster-5.5 might have to skip this release as I want to have a base compatibility of 5.6 for this Debian release. I'm not sure what you mean here. Also, I haven't seen an answer as to which MySQL fork we want for Jessie. We can't have all 3 (or 4?) of them. I've answered already. There are people willing to do work on all of them, and they are significantly different from each-other. Some of those people are actually paid to do this work. I understand this is more work for security, and I don't want to say we have to ship all of them. I'm saying that nobody is going to step forward and say not mine and nobody is going to step forward and say only mine, in part because some people think all three are important. Fedora made their decision with a steering committee, and I believe that decision was at least in part motivated by a business feud between RedHat and Oracle. I don't know if the CTTE would have to be involved, but it may be the only way to choose a course of action unless I am mistaken and members of this team are willing to nominate some of the forks for non-inclusion. My personal feeling is that we should include the ones that have a company ready to stake their reputation on it by committing publicly to maintaining it for the life of Jessie. Oracle? Percona? MariaDB? Want your fork in Debian? Let us know! signature.asc Description: PGP signature
Re: [debian-mysql] MySQL in Jessie
Excerpts from Norvald Ryeng's message of 2014-10-01 11:37:58 -0700: - james.p...@ubuntu.com wrote: On 01/10/14 16:01, Emilio Pozuelo Monfort wrote: If the release team is OK with this, we'll go ahead and upload mysql-5.6 to unstable and raise bugs for the three impacted packages. Please can you confirm. I think it's rather late for such an upload, especially when it involves an ABI break. I asked other RT members and the answer I got also was that it was too late for this. So I'd say we stay at 5.5 for Jessie. OK; upstream support lifetimes are OK for this so should be ok. There's one more issue. MySQL 5.6 is already almost 2 years old. 5.7 is probably released before jessie+1, but the recommended upgrade path is 5.5 - 5.6 - 5.7, so there should be one release with 5.6 first in order to provide an upgrade path. Are you suggesting that mysql_upgrade in 5.7 cannot upgrade from 5.5 directly? That would be most unfortunate. I still don't think we can ship 5.6 in jessie if there are ABI issues. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412189612-sup-3...@fewbar.com
Re: [debian-mysql] MySQL in Jessie
Excerpts from Colin Charles's message of 2014-10-01 11:57:41 -0700: Hi! On 2 Oct 2014, at 00:48, Clint Byrum spam...@debian.org wrote: My personal feeling is that we should include the ones that have a company ready to stake their reputation on it by committing publicly to maintaining it for the life of Jessie. Oracle? Percona? MariaDB? Want your fork in Debian? Let us know! As I have a vested interest in this, I'm shying away from discussion. But MariaDB will support MariaDB 5.5 for the lifetime of Jessie. We have made a similar commitment to Red Hat SUSE for their enterprise releases as well. In order for our friends on the security team to feel good about going forward with multiple forks, this needs to be specific. Not support MariaDB, but maintain the MariaDB packages in Jessie. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412190017-sup-6...@fewbar.com
Re: [debian-mysql] MariaDB in Jessie
Oops, forgot to include debian-release in the response. Excerpts from Clint Byrum's message of 2014-09-13 19:35:51 -0700: Excerpts from Jonathan Wiltshire's message of 2014-09-13 15:01:54 -0700: On 2014-08-26 11:27, Colin Charles wrote: Upstream will publish security releases for many years to come -- it is the choice of Red Hat Enterprise Linux 7, so the commitment is there Can you quantify this? I mean, did anyone actually ask upstream what their support commitment is going to be? Colin is upstream, and while he didn't make it a point to speak with the voice of MontyProgram, I believe he does. However, newer is always newer, so shipping MariaDB 10.0 would be nice if we have time to finalize it after it comes out from the NEW queue.. I agree. 10.0 left NEW on 26th August. Since then, it hasn't been uploaded to unstable, though I do see a version on mentors from yesterday. It has the following problems: - lintian error build-depends-on-obsolete-package - rewrites changelog history It's past the end of transitions for Jessie. Does moving from MariaDB 5.5 to 10.0 in Jessie have any transition implications? There's at least one symbol that goes away completely. AFAIK, there aren't any packages that depend on libmariadbclient. The biggest thing is that 10.0 is not guaranteed to be data-compatible with MySQL 5.5, so care needs to be taken that there aren't any cases where data from MySQL might be converted forward to MariaDB 10.0 leaving the user unable to move back to MySQL. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410707595-sup-4...@fewbar.com
Re: [debian-mysql] MySQL in Jessie
Excerpts from Adam D. Barratt's message of 2014-08-26 09:33:39 -0700: [fixing team@security.d.o CC] On 2014-08-26 10:05, Bjoern Boschman wrote: there are already several patches prepared to start mysql-5.6 transition for sid [0]. It's rather late for that - as per https://lists.debian.org/debian-devel-announce/2013/12/msg8.html , the deadline for accepting new transitions is now less than two weeks away. Sounds like we need to get on our horses and get this moving ASAP. Unfortunately I've no time in the next 2 weeks to contribute. So all I can do is crack the whip. :-P [...] We, generally speaking of pkg-mysql, would favour shipping different mysql-forks starting of jessie. This would include oracle-mysql, mariadb, percona-xtradb-cluster, percona-xtradb-cluster-galera. In general, we (the release team at least, and I believe the security team; please confirm) would prefer _fewer_ forks, not more - particularly when at least some of those forks aren't in testing yet (possibly not even in unstable). This is such a delicate situation. IMO Debian should just ship one, and it should be the one with the most community involvement. However, we have had equal parts help from Percona employees, Oracle employees, and MariaDB users, so I don't really know if we could pick a winner there. This is really a problem that this weird community has created by forking rather than modularizing. It's mind bending sometimes but they all seem to be achieving at least some degree of commercial success while going down this path. So, I can't see Debian saying no to people who are willing to show up and do the work. Therefor my fellow collegues have introduced virtual-mysql packages [1]. Hopefully this helps? Unfortunately, it's actively _un_helpful. The virtual packages lie about what they provide, which makes builds fail when the mariadb packages are installed; see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759309 for an example. Thanks for highlighting this problem. It sounds like the next stop after the transition submission is this bug. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409073441-sup-3...@fewbar.com
Justification for MySQL 5.5.30 going into unstable now
Hello Release team. MySQL in testing is currently 5.5.28. MySQL in unstable is currently 5.5.29. MySQL upstream has released 5.5.30. MySQL 5.5.30 is the current stable release of MySQL. We can anticipate 5.5.31 very soon. I suspect there will be security fixes in that release, although Oracle will not tell me either way. Because we know that there will likely be more security problems found, and that we will likely have to ship subsequent MySQL 5.5 releases in stable-security, I would like to propose that we do everything we can to ship the latest release of MySQL with wheezy. I know that this is not Debian's normal preference, but Oracle has left us little choice. We have packagers working on bringing MariaDB to Debian, and other alternatives exist, but MySQL is so popular that I feel compelled to keep it as well maintained as we can. So, I have prepared 5.5.30 packages and done light testing of them for the last week. I would like to upload these to unstable. These packages also fix one RC bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698068 The other remaining RC bug is a bit more complicated and somewhat lower priority, and I suggest we release without fixing it (or delay the release until MySQL upstream fixes it): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699886 So, I am asking for advice. Release team, should I go ahead with this upload and can I reasonably expect a freeze exception? The packaging diff is summed up in these two commits: http://anonscm.debian.org/viewvc/pkg-mysql?view=revisionrevision=2216 http://anonscm.debian.org/viewvc/pkg-mysql?view=revisionrevision=2217 Thank you for your time and efforts! -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1363933972-sup-2...@fewbar.com
MySQL 5.5.30 does not fix CVE-2012-4414, what to do next?
Please refer to [1] as the rest of this message assumes the reader has read the log thus far. I have just now comitted MariaDB's test for CVE-2012-4414 to the SVN repo where we maintain mysql-5.5 unstable packaging. The package fails to build right now because this test fails. Lifting the test out of the commit is easy. To lift the fix out, is much more complicated. I know it can be done, because Percona did it in their branch. But I do not have the time to commit to such a delicate operation. So, we are left with some options: 1) Un-block unstable's 5.5.29 and let it proceed into testing, which will fix several other CVE's. This will introduce CVE-2012-4414. Its a lower priority fix, so this seems like a valid option if we are pressed for time. 2) Somebody step up and give us a patch for 5.5.30 which fixes CVE-2012-4414. There's probably a commit in percona's tree somewhere that can solve the issue with perhaps some fuzz to resolve. 3) Wait until 5.5.31 comes out, and pray that Oracle have actually fixed this security vulnerability. They've been releasing patch versions on a 2-3 month pace, so we should be able to expect 5.5.31 by late April at the latest. Its actually a good sign that the changelog for 5.5.31 [2] has nothing in it. The security fixes are never enumerated there due to Oracle's non-disclosure policy. We will end up shipping 5.5.31 in the security pocket anyway. This is as much FYI as halp! for the release team. Any advice is appreciated. Thank you [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698068 [2] http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-31.html -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1362762489-sup-6...@fewbar.com
Re: [debian-mysql] Bug#674267: facing upto #674267
Excerpts from Nicholas Bamber's message of 2012-06-19 08:35:29 -0700: I have tested with gcc-4.4 and it seems to work okay. So that is an option. We should do some general performance benchmarks with 4.4 vs. 4.7 before we consider this option. It would be a shame to compromise the whole of mysqld's performance just to improve SSL performance, as only a small fraction of users actually make use of SSL and/or the encrypt functions. I think at this point I'm leaning toward TAOCRYPT_DISABLE_X86ASM on i386 as the short term fix. If Oracle figures out the ASM issue and can give us a patch for it soon, then we can apply that, but for now, this seems the solution that penalizes the fewest users. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1340129052-sup-...@fewbar.com
Re: [debian-mysql] Bug#674267: facing upto #674267
Excerpts from Nicholas Bamber's message of 2012-06-19 11:24:10 -0700: On 19/06/12 19:08, Clint Byrum wrote: Excerpts from Nicholas Bamber's message of 2012-06-19 08:35:29 -0700: I have tested with gcc-4.4 and it seems to work okay. So that is an option. We should do some general performance benchmarks with 4.4 vs. 4.7 before we consider this option. It would be a shame to compromise the whole of mysqld's performance just to improve SSL performance, as only a small fraction of users actually make use of SSL and/or the encrypt functions. I think at this point I'm leaning toward TAOCRYPT_DISABLE_X86ASM on i386 as the short term fix. If Oracle figures out the ASM issue and can give us a patch for it soon, then we can apply that, but for now, this seems the solution that penalizes the fewest users. Assuming we don't just stick one of thumbs in the air, how would you plan to go about this? We could just compare the build times. We could add some timestamps to debian/rules so we can focus on the test part of the build. I don't think I have got much more stomach for any more testing than that as I have dealt with a fair few RC bugs over the past month. I discussed this briefly with Adam Conrad whom knows a fair bit more about GCC than I do. He assured me that 4.4's i386 code would be mostly identical to 4.7's, so there shouldn't be risk of performance regression. So, if 4.4 is indeed staying, then it sounds like a good option to just build with gcc 4.4 on i386, and 4.7 on all other platforms. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1340135638-sup-2...@fewbar.com
Bug#671115: [debian-mysql] Bug#671115: transition: mysql-5.5
Excerpts from Adam D. Barratt's message of Sat May 19 08:51:34 -0700 2012:
On Tue, 2012-05-08 at 06:18 -0700, Clint Byrum wrote:
On May 8, 2012, at 2:04, Julien Cristau jcris...@debian.org wrote:
On Tue, May 1, 2012 at 22:52:22 +0100, Nicholas Bamber wrote:
At some point we need to transition from mysql-5.1 to mysql-5.5. We
would like to do this before the freeze though we appreciate that time
is now short. We arrived at this position as the Debian MySQL Team became
increasingly understaffed. It is better now but not ideal.
[...]
To be fair, this transition was already completed in Ubuntu and I
filed bugs against all packages that failed with patches. Most if not
all of these patches have been applied.
I would expect this transition to go quite smoothly and just to
require rebuilds given the experience we had in Ubuntu.
The problem is that the recent set of php5 security updates are
currently stuck in unstable, because they picked up a dependency on
libmysqlclient18.
For most library transitions, this wouldn't be such a big problem as we
could push the new version of the source in and have britney keep the
old library around in testing for as long as there were
reverse-dependencies; indeed there was some hope that with mysql-5.5
being a separate source package, this would be even easier as the two
source packages could co-exist.
However, it turns out that won't work - the 5.5 packages have:
Breaks: mysql-client-5.1 ( 5.5), mysql-server-5.1 ( 5.5),
mysql-server-core-5.1 ( 5.5)
and there are no versions of those packages with versions = 5.5 (so I'm
not entirely sure what the logic behind the version constraints is).
Various -5.1 packages have versioned dependencies on other binaries from
that source, which means we can't even mitigate the problem by adding
Provides from the 5.5 packages. Providing them as real transitional
packages from the 5.5 source would probably work, unless there's some
reason that's a crazy suggestion?
(There's also a mysql-5.1 upload which can't migrate to testing, as
britney is convinced that it needs mysql-5.5 to migrate first;
presumably because the latter now provides the
mysql-{client,common,server} binary packages in unstable.)
I've done some testing on this. The piece of my.cnf that I thought
would break client and libmysqlclient does not. It only breaks
mysql-server-core-5.1:
120525 0:20:34 [ERROR] mysqld: unknown variable
'lc-messages-dir=/usr/share/mysql'
So the Breaks: on 5.5's mysql-common can be dropped to just
Breaks: mysql-server-5.1, mysql-server-core-5.1
It seems to me that this plan will let things migrate into testing at
that point:
* Upload mysql-5.1 with all unversioned and server packages removed:
libmysqlclient-dev
libmysqld-dev
libmysqld-pic
mysql-server
mysql-server-5.1
mysql-server-core-5.1
mysql-client
mysql-testsuite
* Upload mysql-5.5 (5.5.24 is out and fixes a security flaw) with the
Breaks: on mysql-comon relaxed as above.
This should allow us to progress 5.5 into testing without making anything
uninstallable except mysql-server-5.1, and mysql-server-core-5.1. Users
who have those installed *should* get 5.5 as an upgrade since it
breaks/replaces the -5.1 packages. Their only rdepends in unstable are:
pvpgn - suggests only
|python-mysqldb - suggests, optional 'mysql-server'
mahara - recommends, optional 'mysql-server'
I am still very new to the Debian release process though, so please do
educate me on reasons this would be a bad idea, assuming 5.5 is ready
to migrate to testing.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1337929813-sup-7...@fewbar.com
Bug#671115: [debian-mysql] Bug#671115: transition: mysql-5.5
Excerpts from Adam D. Barratt's message of Sat May 19 08:51:34 -0700 2012:
On Tue, 2012-05-08 at 06:18 -0700, Clint Byrum wrote:
On May 8, 2012, at 2:04, Julien Cristau jcris...@debian.org wrote:
On Tue, May 1, 2012 at 22:52:22 +0100, Nicholas Bamber wrote:
At some point we need to transition from mysql-5.1 to mysql-5.5. We
would like to do this before the freeze though we appreciate that time
is now short. We arrived at this position as the Debian MySQL Team became
increasingly understaffed. It is better now but not ideal.
[...]
To be fair, this transition was already completed in Ubuntu and I
filed bugs against all packages that failed with patches. Most if not
all of these patches have been applied.
I would expect this transition to go quite smoothly and just to
require rebuilds given the experience we had in Ubuntu.
The problem is that the recent set of php5 security updates are
currently stuck in unstable, because they picked up a dependency on
libmysqlclient18.
For anything critical like the PHP update, would it be prudent to upload
a new one with the build dependency bumped back to libmysqlclient16-dev
so they can progress to testing independent of this transition?
For most library transitions, this wouldn't be such a big problem as we
could push the new version of the source in and have britney keep the
old library around in testing for as long as there were
reverse-dependencies; indeed there was some hope that with mysql-5.5
being a separate source package, this would be even easier as the two
source packages could co-exist.
However, it turns out that won't work - the 5.5 packages have:
Breaks: mysql-client-5.1 ( 5.5), mysql-server-5.1 ( 5.5),
mysql-server-core-5.1 ( 5.5)
mysql-common 5.5 will break 5.1 because there are new configuration
options used in /etc/mysql/my.cnf that will *break* mysql 5.1, as in,
it will refuse to run, libmysqlclient will throw errors, etc. This is
an unfortunate, but necessary evil.
We can upload a version of 5.1 that has no mysql-server, mysql-client,
or mysql-testsuite packages, and also that depends on a mysql-common-5.1
which breaks/replaces mysql-common ${binary:Version}, and conflicts
with mysql-common ${binary:Version}, so that everything remains
installable during the transition. mysql-common in 5.5 would also then
need a Breaks/Replaces of that package to handle upgrades properly.
and there are no versions of those packages with versions = 5.5 (so I'm
not entirely sure what the logic behind the version constraints is).
Various -5.1 packages have versioned dependencies on other binaries from
that source, which means we can't even mitigate the problem by adding
Provides from the 5.5 packages. Providing them as real transitional
packages from the 5.5 source would probably work, unless there's some
reason that's a crazy suggestion?
(There's also a mysql-5.1 upload which can't migrate to testing, as
britney is convinced that it needs mysql-5.5 to migrate first;
presumably because the latter now provides the
mysql-{client,common,server} binary packages in unstable.)
The above idea would allow testing users to get the new 5.1 updates
while we finish the 5.5 transition. I'm not sure how important that is.
Perhaps I don't understand the transition process though.. how long will
it actually take? I'm really sorry for the total lack of understanding of
that process.. in Ubuntu where we don't have maintainers, I completed it
in about 2 days of no change rebuilds, and 1 day of patching the obvious
FTBFS's. The rest of the transition was actually fixing the 2 or 3 big
incompatibilities. With all of that work already done and those patches
submitted to all the Debian packages/upstreams/etc., I'd expect things to
go more smoothly in Debian. I understand there are more architectures, but
will it really take so long that we need to keep the 5.1 packages healthy?
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1337624131-sup-5...@fewbar.com
Bug#671115: [debian-mysql] Bug#671115: Bug#671115: transition: mysql-5.5
Excerpts from Nicholas Bamber's message of Mon May 21 12:47:19 -0700 2012:
On 21/05/12 20:21, Julien Cristau wrote:
On Mon, May 21, 2012 at 11:34:16 -0700, Clint Byrum wrote:
mysql-common 5.5 will break 5.1 because there are new configuration
options used in /etc/mysql/my.cnf that will *break* mysql 5.1, as in,
it will refuse to run, libmysqlclient will throw errors, etc. This is
an unfortunate, but necessary evil.
We can upload a version of 5.1 that has no mysql-server, mysql-client,
or mysql-testsuite packages, and also that depends on a mysql-common-5.1
which breaks/replaces mysql-common ${binary:Version}, and conflicts
with mysql-common ${binary:Version}, so that everything remains
installable during the transition. mysql-common in 5.5 would also then
need a Breaks/Replaces of that package to handle upgrades properly.
I'd rather see a new mysql-5.1 upload that builds *only*
libmysqlclient16.
fixed top post
That should be trivial. We need only remove all the other binary
stanzas, right?
You will also need to fold /etc/mysql/my.cnf into libmysqlclient16 as the
library needs that file for default settings, and then you need to make
it conflict with mysql-commont = 5.5 so as to not pick up the broken
config options.
Either way, basically nothing that depends on libmysqlclient16 will be
able to be co-installed with anything that depends on libmysqlclient18.
Welcome the to the crack that is libmysqlclient. :)
I will do some tests, maybe we can get the two libs to share a common
transitional library only my.cnf.
But, I think really we just have to finish the transition ASAP.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1337648315-sup-6...@fewbar.com
Bug#671115: [debian-mysql] Bug#671115: transition: mysql-5.5
On May 8, 2012, at 2:04, Julien Cristau jcris...@debian.org wrote: On Tue, May 1, 2012 at 22:52:22 +0100, Nicholas Bamber wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition At some point we need to transition from mysql-5.1 to mysql-5.5. We would like to do this before the freeze though we appreciate that time is now short. We arrived at this position as the Debian MySQL Team became increasingly understaffed. It is better now but not ideal. We certainly will get mysql-5.5 into unstable in the next few weeks. The question is can we migrate all the dependencies over and drop mysql-5.1 before the freeze? *sigh* apparently you uploaded this to sid without even waiting for an answer, so we now have an uncoordinated libmysqlclient SONAME bump on our hands... To be fair, this transition was already completed in Ubuntu and I filed bugs against all packages that failed with patches. Most if not all of these patches have been applied. I would expect this transition to go quite smoothly and just to require rebuilds given the experience we had in Ubuntu. If that fails then we will be left supporting a version of MySQL that is not supported upstream. Given how well that support works anyway I'm not sure how much of a loss that is. I'm not sure that is fair to Oracle. While their policies around security disclosure are a bit baffling and perhaps dangerous for their users, they are responsive to bug reports and still provide changes as individual commits in public bzr trees. Oracle deserves our ire, but Debian users who depend on MySQL will be better served by 5.5 than 5.1. As far as I can see the upstream packages that are likely to require recompilation are: That's an awfully long list to be breaking without coordination. I'm not amused. Cheers, Julien ___ pkg-mysql-maint mailing list pkg-mysql-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6cea35e9-a2f8-4c64-b63d-aeeb0767e...@ubuntu.com
Re: Bug#594607: libdbi upload to SID reverted (was: Freeze exception for libdbi and libdbi-drivers)
You're timing is fine from my point of view Markus, this should be enough time to fix for 10.10. We'll be in beta freeze for 10.10 for another week or so. Upon importing the tarball into the ubuntu package, it builds correctly with libdbi.1.0.0.so. I was also able to build libdbi-drivers, including the testing suite, without errors (nice to have those tests! :) There is some more work to do, namely renaming libdbi0-dev to libdbi-dev (as it should have been originally I think) and renaming libdbi0 to libdbi1. Then we'll need to tweak all of the packages that build-depend on libdbi0-dev to libdbi-dev, and rebuild them. As far as squeeze goes, this probably won't happen. But it should be doable for Ubuntu 10.10. Markus, thanks for pushing this out quickly! On Aug 31, 2010, at 4:46 PM, Markus Hoenicka wrote: Clint Byrum writes: I believe all that is needed is to bump 'LIB_CURRENT' in configure.in from 0 - 1, and autoreconf. Hi, I hope it's not too late, but I've prepared a 0.8.4 test tarball: http://libdbi.sourceforge.net/downloads/libdbi-0.8.4.tar.gz This isn't officially released yet, but I could do so in no time. Please have a look at the tarball and let me know if this serves your immediate needs. I've used the 0.8.3 sources and changed the following things: - bumped the package version number to 0.8.4 - updated some autotools-related things in configure.in, autogen.sh, and Makefile.am (recent versions need AC_CONFIG_MACRO_DIR set properly, otherwise I wouldn't be able to bootstrap the build on my FreeBSD development box) - LIB_CURRENT=1, LIB_REVISION=0, LIB_AGE=0 - fixed the --disable-docs behaviour of configure (this had been fixed long ago in HEAD) regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca57dc32-4e93-4e9d-92d4-071ad37c4...@ubuntu.com
Re: libdbi upload to SID reverted (was: Freeze exception for libdbi and libdbi-drivers)
On Aug 28, 2010, at 1:49 AM, Thomas Goirand wrote: Now, version 0.8.2 is back to SID. I can't upload a new 0.8.3 to experimental, because I need you to change your so version number before I can upload (otherwise, there's collisions). Please let me know when I can download a new fixed version of the 0.8.x series, and upload it to experimental (so that Ubuntu gets a chance to have the new package we've been working on before 10.10 is out in few month, which was the motivation of Clint Byrum). Markus, it would be great if an 0.8.4 or 0.8.3.1 release arrived with soname bumped. We could just rebuild all of our rdepends, but then anybody who has depended on libdbi0 will break when the new version arrives. Either way, I'd prefer not to revert to 0.8.2 in Maverick, being in Beta freeze right now. Its much better if we can just upload the new version, and then rebuild all these rdepends: $ apt-cache rdepends libdbi0 libdbi0 Reverse Depends: syslog-ng python-gammu-dbg python-gammu libgsmsd7 libdbd-sqlite3 libdbd-sqlite libdbd-pgsql libdbd-mysql libdbd-freetds libapache2-mod-log-sql-dbi libapache2-mod-log-sql-dbi icinga-idoutils gammu-smsd collectd-core collectd rrdtool rrdcached librrd4 liblua5.1-rrd0 libdbi0-dev I have created a bug report in Ubuntu to link to the Debian report. https://bugs.launchpad.net/debian/+source/libdbi/+bug/625882 I believe all that is needed is to bump 'LIB_CURRENT' in configure.in from 0 - 1, and autoreconf. Markus, please let me know if we can do anything to assist with this, its fairly urgent, but not something we can really work around with a patch. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/42c4981d-10ea-4486-8b83-9b1fdffbd...@ubuntu.com
Re: Please consider migrating gearman-interface 0.13.2-2 to testing
Hi Adam, thanks very much for taking a look! On Aug 21, 2010, at 11:45 AM, Adam D. Barratt wrote: On Sat, 2010-08-21 at 09:17 -0700, Clint Byrum wrote: * debian/rules: moving tarball .c files out of the way so swig will rebuild and ship the .py files. (Closes: #593642) So far as I can see, this: [ -f python/libgearman.c.orig ] || [ -f python/libgearman.c ] mv -f python/libgearman.c python/libgearman.c.orig || true will attempt the mv if python/libgearman.c.orig exists but python/libgearman.c does not; was that intentional? Definitely not. The intention is to only do the move if libgearman.c.orig does not exist, and libgearman.c does. I suppose this actually does the same thing: mv -n python/libgearman.c python/libgearman.c.orig || true * add description of gearman to long description (quiets lintian) * Removing unnecessary build depends on ruby/rubygems * Version build-dep on python3 * change python:Provides to python3:Provides * re-enable dh_usrlocal Why was the override added in the first place? Somehow this slipped through, it was overridden during a bit of frantic iterative building/failing early in the package's life, and never re-enabled, but the override was never actually necessary. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/099a39c8-c386-4014-92db-0ef499e86...@ubuntu.com
Please consider migrating gearman-interface 0.13.2-2 to testing
Hello Debian Release Team, and thank you for your hard work! I am the maintainer for the gearman-interface source package. I hope that you will consider migrating v0.13.2-2 of gearman-interface and its associated binaries, python-gearman.libgearman and python3-gearman.libgearman, into testing, rather than dropping them. Currently the version in testing has this grave bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=593642 0.13.2-2 was recently uploaded to unstable, and fixes the problem, which is purely a build issue. It has this changelog: * debian/rules: moving tarball .c files out of the way so swig will rebuild and ship the .py files. (Closes: #593642) * add description of gearman to long description (quiets lintian) * Removing unnecessary build depends on ruby/rubygems * Version build-dep on python3 * change python:Provides to python3:Provides * re-enable dh_usrlocal * Added watch file Because the python3 change adds a versioned build dependency on python3 (= 3.1.2-6~), it will have to wait for python3 3.1.2-6 to migrate into testing, which I see, has already been granted an exception and should be migrated in 3 days. please cc: me on any replies as I am not subscribed to debian-release. Thank you for your time, -- Clint Byrum -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ab857f62-2c96-417b-9826-01052ba4e...@ubuntu.com
Re: Suggestion: Release sarge without security support
On Mon, 2004-11-22 at 19:13 +0100, Florian Weimer wrote: * Andre Lehovich: On Mon, 22 Nov 2004, Florian Weimer wrote: Why can't we treat security support like a broken package, and remove it if it isn't fixed by its maintainers? The security team are doing a great job supporting Woody. But only if the basic infrastructure to do their job is in place. If there isn't a full set of buildds, they are screwed. (AFAIK, we don't have a full set of security buildds for neither sarge nor woody right now. Not the fault of the security team, of course.) This brings up something that has bothered me for months. Help me out here. I'm not a debian developer, but I'm an avid user (since slink), and a believer in the concept. What really annoys me is that there is a tyrrany of the minority in Debian. How many people are running Debian on MIPS? What about on s390? Lets face it, its hard to get things to work exactly right on what, 11 architectures? If you remove security, the users will never forgive you. If you remove MIPS, and s390, and maybe 1 or 2 other obscure and problem ridden arches, the users will praise you, and probably those few that needed those arches will understand. I'm willing to wait for Debian's stable releases. They are glorious and legendary in their correctness. But please please *please* stop this madness. -- Clint Byrum [EMAIL PROTECTED]
Re: Suggestion: Release sarge without security support
On Mon, 2004-11-22 at 20:53 +0100, Andreas Barth wrote: Furthermore, d-release is _not_ a discussion list. Point taken, and discussion ended. -- Clint Byrum [EMAIL PROTECTED]
Why is sarge 3.1?
Forgive me if this has been discussed before. I searched the archives of debian-user, debian-devel, and debian-release, and saw nothing about htis. It appears that Sarge will be called 3.1. Why is that? I personally think it should be 4.0, as do many others I have spoken with.. 1) Kernel v2.2 is no longer available on install, much less the default. 2) The installer was totally rewritten. 3) [the big one] gcc-3's C++ ABI is totally incompatible with gcc-2.95's. This alone should force a major number upgrade. What if I have my critical custom C++ applications running on woody, and I see Oh, 3.0 to 3.1.. I'll dist-upgrade, its no big deal .. blammo, everything breaks! Am I crazy? Is it too late to bring this up? Wrong forum? Sorry if I seem a little lost.. but I am. I'm surprised nobody has brought this up recently.. which is why I suspect I've missed something here.
