 The principle maintainer of the MariaDB packages in Debian, and I work for the MariaDB foundation, so I have a possibility to invest a lot of time in making those packages properly and keep them maintained well, and at the moment there are no others from the package MySQL team here at Cape Town, but Robbie should be listening in via the stream hall, is Robbie listening? Cool. Great. You can also go to that IRC channel if you want to participate in the IRC discussion. Right. So we have a MySQL team in Debian and in Ubuntu, and it's a very old package, and it's a very big package, so over the years there has been lots of people involved, but at the moment there are not very many highly active people. I'd say we have four active people at the moment, and the most active ones, two most active ones is me taking care of the MariaDB package and Robbie Basak, who is a canonical employee taking care of the MySQL package. And we are looking for new contributors because obviously this is a huge package, and it has a lot of dependencies, and now something happened to the sound. It's okay. Yeah. So how many of you are Debian developers? Great. How many are Debian maintainers or aspiring to be Debian developers? So if you help us with packaging, we are happy to help you on that path. All right. Here's an overview of what the team maintains in Debian at the moment. So this is very small, but I'm sure you all can go to qa.debian.org and look at this on your own laptop yourself. So there's the Galera package, MariaDB package, MariaDB client libraries, LVM backup, MySQL 5.5 in stable, MySQL 5.6 in unstable and testing. No wait, old stable has MySQL 5.5, and we have a MySQL connector, MySQL proxy, and they have Percona extra backup. So mostly the situation is pretty stable and good, but we have all kinds of annoying stuff like, for example, the builds are not reproducible and there are some architectures we have build failures and so on. And the change that's happening now in this release cycle is that the release team said that they want to have MariaDB as the default. And there has not been any kinds of facilities before to define a default, so we are introducing now new meta packages. And this is how the plan looks like and maybe if you, Robbie, are listening in, you can comment if this is the latest plan or have you done any updates in the recent hour or so. So this is very much work in progress and it's fully open to discussion and contributions if you want to say something. So the idea is to have a new source package called MySQL defaults. Robbie is giving thumbs up, great. And that source package is going to produce a few meta packages and all packages that previously depended directly on MySQL or later on MariaDB should in future depend on these meta packages. And these meta packages then point to the version which the release team decides is the default at some time. So if you have a normal runtime dependency, you would write something like this. This scheme with virtual MySQL server already exists. We are going to keep it at the moment. And if you have build depends, then you should change it to build depend on this meta package, which then does some tricks and uses the LibMySQL client 18 from MariaDB at the moment. And then in future it might use another version. And I have typos here. Liby, yeah. So I guess we could stop here for a while. I have a bit more of presentation, but this is a buff. So let's take a pause here and listen into your comments about this. How many of you have a comment? Where should I switch to now? Yeah, so if you have a new installation, if you have a new installation and you write, for example, up get install WordPress and WordPress depends on this and you don't have any MySQL variant installed, then it will take the first option and it will pull in MariaDB at the moment. And if you have installed manually something else which provides this, then that will stay and it will not pull in the default. And if you have an old server which has some database installed, then actually depending on what packages you have that depend on that database, you get a different kind of result. And to the question how stable it is, well, I can't really say I know that I am maintaining MariaDB packages in a very stable fashion and for a long time. So it's basically the release team who should comment on how often they want to change this default, but probably not very often. It was mentioned that MariaDB is more compatible than MySQL itself. So the question is if something happens to MariaDB, can we go back to MySQL? Yeah, so the idea with this is that the release team specifically wanted to have a facility so that there's one point where you can turn the knob and change the default instead of doing a mass bug filing on 200 packages. You just have one meta package and you need to upload a new version of it and then the default changes. And that facility exists for the reason that the release team can make these kinds of decisions and they want to be able to make these kinds of decisions in case there is something that suddenly comes up and you need to change the default. So I think that the dependency resolve mechanism in Debian should not change your currently installed packages if we follow the scheme because all the providers are at the second level. And if it's already installed on your system and your dependency is already okay, then it doesn't need to install anything new. So it will not install the default if the other one is already there. Yeah, right. So your question was about stability and backwards compatibility. Yeah, so I need to upgrade my server so I'm wondering which version should I use now. So should I stay with MySQL, which is already working fine or MariaDB 5.5, which is working fine or go to 10.0.2? Well, I think that you should at some point obviously you need to upgrade from 5.5 versions to something newer and since I represent MariaDB, I think it's better. But of course admins can make their decisions if they feel that there's some specific feature in MySQL 5.6 or 5.7 that they want to use and so on. But if you don't care, then you just install the default. I think he was asking really you to what you recommend. Yeah, well I recommend MariaDB, but you know that's kind of obvious. And what Sergei was saying about compatibility and the stability, your question was about stability. So there was a fork at the 5.5 level and at that point MariaDB is 100% ABI compatible with MySQL. Now it's maybe 99%, but it's not like applications use 100% of the features that mostly it's just the basic stuff. And I think that's probably gonna be compatible forever. And I know that at least in MariaDB development we test that upgrades from earlier versions of MariaDB work well and that upgrades from MySQL work well. So to my knowledge at least that path should work and then you have to ask Oracle people how much they want to support backwards compatibility. There has at least been, Paul had some issues in Ubuntu when they introduced MySQL 5.7 and stuff broke because it wasn't properly backwards compatible with 5.6. So that this is kind of the intent, but then of course it's software and it has bugs and people can't know all the features that's everywhere. So we can't maybe promise anything, but I think it's good that we have this facility so that it's possible to easily change and fix stuff if it starts breaking. So one of my packages built depend on MySQL. So I understand that currently that should not be an issue, either one. What do you think that, yeah, so it's future looking, but what do you think? Yeah, so if you build depend then you should update to this and this will use the MariaDB provided LibMySQL client 18. And it doesn't matter because the client library will work with either one of the versions when it talks to them. The ABI is compatible and it's close enough. And if you have, for example, the MariaDB Node.js library, which uses asynchronous functions that are only available in MariaDB, then you can't rely on this, then you should specifically build depend on the MariaDB client library version. So that's a corner case, but I think like 99.9% of the software in Debian can just build depend on this and everything will work with both client library versions. So it's a fork of the same base and they have different feature sets in new features and they are not kind of super sets of each other. They are going to different directions, but the base is the same and pretty much all the apps use the base. Well, luckily my package hasn't changed in a while, so I'm pretty sure the reports just work. But at some point there will probably be something breaking, but that's not perhaps specific to the MariaDB fork. That's also something that happens naturally when there are new versions of software, their API gets new API versions and the surname bumps up and so on. So we are prepared for those cases, I think. Any other questions? So how many are maintaining a package that currently depends on MySQL server or virtual MySQL server? Pearl guys at least have one package. Yeah. You know, don't server I guess on the library. I mean, well, DVD MySQL. Yeah, that one. It depends on live MySQL client and in future it should depend on this. There's multiple packages recommending of course the server, but because it's a remote database, they typically don't depend on them. Yeah, so this is common for MySQL and MariaDB. MariaDB, and as I said, this is the team and the packages they have. Do you want to discuss something related to any of these packages? Do you have any needs or concerns in general related to the state of this? So at the moment we have MariaDB 10 in Jesse and in testing an unstable and we have MySQL 5.5 in old stable and MySQL 5.6. This says it's available in old stable too, which is new to me. Somebody was doing some back porting. It was you. So is there 5.5 in Jesse? Yeah. Do you prepare the 5.6 back port to Jesse? Yeah. And 5.7 is in the works. I will upload it into Debian soon. So then we will have MySQL 5.7 and then MariaDB 10.2 is also in the works and it will be introduced also soon. I also still want to relay some comments from Robbie on the IRC. It was to the question of the compatibility. Robbie said, he said the biggest issue right now is that you can't easily switch from MariaDB to MySQL. So apparently the way to MariaDB is okay, but the other way around not because the DB formats do not carry over. You must manually dump, restore and tweak as necessary. A newer upstream versions of MySQL have been cleaned up, which breaks some compatibility, for example in locking down things in a schema, which made no sense anyways. Primary key columns being runnable, etc. Deprecating LibMySQL client R because MySQL client is now thread safe. This kind of things is what has been breaking compatibility in MySQL 5.7, which I was observing my package breaking in Ubuntu. You also had the example of the parameter which changed logic that it doesn't accept empty values anymore. MySQL 7 has been cleaning up stuff, which means it has broken some stuff that is backwards compatible. But of course nobody, this is normal evolution in software and we are talking about compatibility on different levels. Can you switch back and forth and can you use the same data format on disk or not? And most of the time system administrators who are smart, before they do a disk upgrade, they will make a dump and backup of their database and they will make that in an SQL dump format and so on. And that format is pretty portable and you can take it into new places and so on. So you need to keep in mind that when we are talking about switching back and forth, we are talking about how easy it is or is it difficult. But probably you are not locked in any situation. You can always do a manual dump and transfer the data into a new installation. So how many of you are making backups of your database? Great. What backup techniques do you use? MySQL dump, LVM snapshots, yeah? Are you using this MyLVM backup package to do it? Yeah? Is somebody using Percona extra backup? Yeah, cool. And is somebody using bin logs in a backup fashion? Yeah. I think that's maybe an area which should be improved a little bit because there are... I have a request in DPConfig common as well of making backups an option there. Is there anything from Robbie on IRC or somebody else on IRC? Just a comment on the previous discussion he imagined that fixes needed for 5.7 will still work with MariaDB also. Yeah, right. So this we already discussed and I said if you... We will start by uploading this to experimental and then you can test out in experimental or you can review our plans at the moment in Git and comment them on plan level or you can wait until they are in experimental and then test in experimental and comment them and request changes. So this is the hot thing which we are doing right now. And then for MariaDB which I'm the main maintainer for, I have some easy to-do issues which I have put up in the bug tracker. And this is specifically designed with new contributors in mind that you don't need to learn overly too much about the current state of packaging and dependencies and stuff. These are independent jobs and you can go to this address to see all wish list level items and I have prepended them with to-do. So if any of this looks interesting to you and you could do it easily then please by all means step forward and contribute by helping with them. Do we for example have some system D expert in the room? Because we are still running the traditional init script and we should have a native system D script in Debian. How about do you have any metadata.yml experts here? How about auto package tests? Could somebody want to contribute them? It's actually quite easy to do them because you can look what MySQL packages are doing at the moment. They have auto package testing in Debian and Ubuntu. You could just start by copying that and reviewing it and maybe tweak it a little bit and then it's done. Just before you go on I have a message here from Jason on ISC. He wants to congratulate you and the Debian team and MariaDB team on the effort that you've done with development. So he's saying you're doing great job. Thank you. So these are the easy ones. On a somewhat unrelated note I'll check MySQL packaging and they do not use open as they use YSL. Let's show I just check the dependencies. So I also checked this just before this talk. So here are some more difficult to do items. So reproducible builds are broken and they are broken for different reasons. But at the moment MariaDB was working correctly for a while. But then something broke and it's very difficult to debug what broke because something is introducing a build ID into the TokuDB plugin. And we haven't been able to track down what does it. It has something to do with the Debian debug builds or something with how reproducible builds are done because it doesn't repeat on normal builds on our own machines and so on. So do we have some reproducible build experts who would like to tackle that one. So it's just one minor thing left and after that the builds are again reproducible. But this is just hard to crack. Have you asked about that on the mailing list? No. Would you like to contribute by hanging on IRC or on the mailing list? I would suggest that even go on IRC here at that conference just ask who's around to have a look at it with you. There are plenty here. But I think for the rest of the evening and so I'm tied up to this default package thing building and testing it. So this is kind of a separate issue which doesn't need involvement from me. So it would be really nice if somebody else would investigate and just send a patch when it's done. We're all busy. And I'm happy to add you to the package MySQL team if you want to have direct push access to it repository. You have a question. So my question is really not technical but I was I was wondering about the what Meridibi like the organization is how it's funded. Is it a non profit thing or yeah. So there's Meridibi Corporation which for example Sergei works for and you can ask more about the corporation from Sergei. It has I think something like a hundred employees and it does all kinds of commercial work and support services and commercial versions and so on. And I myself and iron work for Meridibi Foundation which is non profit and we are funded as I in my previous talk actually presented a little bit about it. So we are funded by by multiple. We have individuals who donate to us and then we have corporations who donate to us for example booking.com and Visma. And Meridibi Corporation is one of the sponsors but it's the amount that they give is only 20 percent of the entire budget. So we are financially independent and the foundation has all the needed assets. So if something happens to the corporation we can continue the open source project. Our our task is to take care of the open source project and make sure that this software is around for 20 30 40 years or how long you have databases running. Another question on ISE from Jayton. Is it necessary to be a DB developer to help in the to do stuff? No absolutely not. So the only magic power you get as a DB and developer is that you can do uploads and stuff. But but anybody who wants to participate can just start cracking the problem. And for example we have the Git repository so you can you can just clone it and make changes and then submit your patch. And if you submit multiple patches then I can add you to the team so you have direct push access to the repository. There's also a mirror on the on GitHub. So if you want to use GitHub workflow with forks and pull request there that's also possible. And so here's here's information and there's a sub page teams slash my skill slash Meridibi if you want to take a look. And I'm happy to happy to help you especially if you aspire to be a debut maintainer debut developer someday. So I'm happy to volunteer as your sponsor in that case. All right and then then the second tough question. So did we have any security team members here? No so at the moment both my SQL and Meridibi use are built with the bundled. Yassel SSL library instead of open SSL and so the ideal perhaps would be to use the system provided open SSL. So if there's a hard bleed or something like that then one single security upload into Debian will fix the system open SSL. And then the security team can just retrigger a build and or not even retrigger a build. It's just enough to start the demon and it will load a new library and so on. So for security point of view it would be nice to have a system provided SSL library. And some something that open SSL is the best variant. So I don't know but at least there's this licensing question that at the moment stops us from using open SSL. So this is a typical open SSL exception to the GPL. So one way would be for Oracle and then Meridibi to add the exception so the license which I'm guessing is a hard thing to do. But open SSL upstream has expressed that they are switching the Apache license. Instead of the open SSL license so eventually this will be fixed not just for Meridibi but across the archive. It will take some time. They're tracking down all contributors and licensing and all that. They have probably loved about it. There are also alternative SSL versions like CSL which is now called Wolf SSL and Libre SSL and so on. But these alternatives have the problem that they are not maybe mature enough. So if we wait enough we will by time will solve this so that either open SSL will become Apache licensed or some of the competing libraries will become mature enough. We can start using them. GNUT LS is also a good option. It's GPL so it wouldn't be a conflict and it is mature enough. Which one? GNUT LS. So is that separate from Libre SSL? Libre SSL is an open SSL fork. Okay. No I just said that Libre SSL is basically the same as open SSL same license. Slightly cleaned up code. License wise GNUT LS is possible and NSS may be possible. And maybe CSL if it will have another functionality. So time will help fixing this problem but is there something we can do right now? I wonder. How old are the comments on this bug? I guess Debian doesn't really have a really authoritative person to actually comment on that. So typically this goes via the legal mail list. So it's more of a consensus thing right? So yeah. Well the legal mailing list is a bit of a talking shop and some of the people on it talk a lot. And they are not related to the FTP masters who actually accept things. So there's a complete disconnect there I would say. The talking people on the legal list have driven away quite a lot of the same people. So I think it's a real shame we've got that list. Because it confuses outsiders who aren't aware that Debian legal is just a place where people chat. So go to FTP master. Is there somebody who has deeper knowledge about this open SSL exception thing and what's the legal status about it in general? And do we need to care about it or would it be okay to ignore it and so on? Probably not. Do you have something else you want to discuss? It's a both session. I don't have any more questions here. I have a question. So the MariaDB and MySQL maintenance scripts right now create a Debian sys main user and run some things over the course of installation and upgrades such as upgrading schemas and stuff like that. So that is clearly not suitable for larger installations like multiple slaves that you want to control the data and use schema. So I'm wondering if there's, have you thought about to saving that in... This was my previous talk. This solves the problem. Okay, I missed that. So we get rid of passwords altogether and the maintenance user is a legacy thing. So there's a main, let's show it here. Yeah, so you are talking about this Debian sys main user and password. So there's a plain text password in the ETC directory and the only thing that's protecting it is the Unix file permission. And this user has root level access into the database in MySQL and MariaDB. So in MariaDB we have started using Unix socket identification. So we get rid of this password altogether and root can access the database. The system linux root user can access the database and run the MySQL upgrade scripts and stop it and start it and so on. Right, but I'm talking about not running the upgrade scripts at all. In some cases you don't want an upgrade on a system to run upgrade scripts. Because you're doing that externally you have more complicated environments. I don't know if the binary is upgrade then you kind of have to run the upgrade on the data, on disk data. There were a few things that haven't looked in a while. There were a few things that needed to be avoided. There were some queries that were run by the mention of scripts that didn't play well with the application. But I don't remember the details. In most cases it's recommended but it's really strictly required. So it makes sense to run without if you can and if it works for you. If it works for you then it's not a requirement. Do you remember what was the exact problem? What happened? This solved the password thing and then in general the upgrade should be safe and work. That's kind of an upstream problem I think. So I have a master slave set up and when I upgrade packages there then there are some things running during the upgrade, updating some internal databases. And that often causes a problem with the replication. So the replication errors because on the master the database has already been upgraded and then the same thing happens again on the slave or the other way around. So this is kind of related how to master slave replication works and how it's compatible if the binary is on disk format changes. So I think you should maybe when you notice the exact problem and file a bug about it. I'm not sure there's any categorical solution to avoid it. In general it should work fine if you have a Galera cluster or a master slave set up that you don't need to synchronize too much the upgrades. They can have slightly different binary versions, minor versions as long as the API version is the same. Yeah, I'm using the same versions but I think it's generally recommended to first upgrade the slaves and then upgrade the master. Okay, say it again probably as a reply to this. When did you have this issue? So when did you have it last time? Approximately like this year, last year, I don't know. Of course I just found in the bug database, maybe we have great breaks replication and the description of the bug starts from Debian starts script for MariaDB in Debian slash edition and so on and it was fixed and closed in 2013. So three years ago it was closed in our repository maybe took a while until it got to Debian packages but yeah for the bug it was fixed three years ago. It's MySQL version 5.5 that I'm using so it's stable maybe that's fixed now. Maybe it wasn't fixed in MySQL packages I don't know about that but we had it when we fixed it three years ago. You're welcome. So do you have any opinions on back porting? Should we, is there something that's justified important enough and justified so that we should back port it in back ports or in a point release into a stable? Do we need something in Jesse that's not there at the moment? So I think I'm happy with the existence of MySQL 5.6 in back ports. I'm not super enthusiastic about being the one, the only person that back ports it. So if somebody else cares that would be nice. Maybe we can talk about that separately as part of the team. Yeah so back port is kind of easy because we don't force anybody but I was talking about do we need some updates to the stable releases. At the moment purely security we do only purely security releases into stable and we haven't done any bug fixing or things like that into the stable releases. Are you aware of any serious bug that should be back like fixed in a stable release? Do you have a question? Let's check on IRC if Robbie has something or somebody else on the channel. So the remark from Robbie, as I understand it, in MySQL we still need DB and SysMain to run MySQL upgrade again. I think that was said here as well. The problem comes when a user wants to have a different route authentication plan, that's not a Unix socket. There's always the option to use MySQL server core and take care of managing the database manually for larger installations example clusters. MySQL server core provides the binaries only now automated maintenance. So if you don't want to run the updates apparently there's a package available. There is both client core and server core packages in MySQL and MariaDB, which you can use for these kind of use cases. And also this socket authentication is default now and implemented only in MariaDB. It's not in MySQL yet, but I think MySQL is probably going to have it too soon. So MySQL still has the DB and SysMain user. And this also applies only for new installs. If you have an existing user database and everything then those passwords will continue to stay there. Time's up. Thank you for participating. I hope to see some activities.