[06:32] new podcast today? [06:51] hey bittin - yep, I have just finished recording it in fact - will need a bit more time to edit it and publish it so expect something in an hour or two 😉 [06:51] alright :) [10:15] listening now [14:29] hi security, we have an FTBFS of mariadb-10.6 in jammy [14:30] uploading a fix just because of that might not be optimal for jammy users (restarting a db post-upgrade) [14:30] but if you ever decide to do a security release, you will hit the problem [14:30] what's the best way to deal with this? Use a block proposed tag? [14:38] (and the ftbfs is only in launchpad, which is using a focal kernel as a base) [14:38] if you boot jammy, and rebuild it there, it will work [14:38] problem is jammy with a focal kernel, which is what is used in the launchpad builders, ppas inclluded [14:39] so even less likely to be hit by users I think [14:43] ahasenack: yeah, a block in proposed seems reasonable [14:43] ahasenack: or just ping otto who usually does the mariadb updates that we sponsor [14:46] the fix is included in the debian package already [14:47] (even though it only affects ubuntu) [14:47] but does otto also do SRUs? [14:49] mdeslaur: ^ [14:55] I don't know if he does SRUs...filing a bug about it with a pointer to a patch is fine too, either we'll find it or he will [14:57] ahasenack: ^ [14:57] oh, the bug exists [14:57] I'll go with the block proposed tag [14:57] am also waiting for one affected user to come back and say what exactly is his scenario [14:58] sounds good [17:43] ahasenack: the scenario is running mariadb in a docker container with jammy on a host running focal. this is part of migrating a kolla openstack deployment from focal to jammy. one could discuss whether updating the host first could be required to avoid this issue [17:45] frickler: but I didn't see the bug happening with the current mariadb-server from jammy [17:45] frickler: I tried with a jammy lxd on top of a focal host, thus the focal kernel [17:45] which should be very much like what you are describing [17:45] it did happen with the -3 release that was in jammy for a while, before the release [17:45] but not with 2ubuntu1 which is in jammy now, unless I made a mistake [17:48] ahasenack: https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_bd5/839585/23/check/kolla-ansible-ubuntu-source/bd5a051/primary/logs/kolla/mariadb/mariadb.txt [17:49] Server version: 10.6.7-MariaDB-2ubuntu1-log [17:54] frickler: do you build that docker image? [17:54] or is it someone elses? [17:55] because if mariadb 2ubuntu1 is rebuilt on jammy, it will hit the bug [17:56] the build process runs tests, and these tests fail, so you won't get a package out of it, unless the tests are skipped [17:57] frickler: I guess I'm asking if the dockerfile rebuilds mariadb before putting it in the image, or just grabs the built package from ubuntu jammy [18:06] ahasenack: the latter, the build log is also there https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_bd5/839585/23/check/kolla-ansible-ubuntu-source/bd5a051/primary/logs/build/mariadb-server.log [18:06] those are upstream ubuntu pkgs just fetched from a local mirror [18:07] * ahasenack scratches head [18:08] maybe there is something wrong in my test case, let me run it again, carefully [18:08] frickler: thanks for the data [18:09] ahasenack: sure thing, let me know if I can test something on our end [18:11] frickler: well, this ppa has a build with the fix: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4871/+packages, for jammy [18:11] it might not be all published yet, it's waiting on riscv64 [18:11] but individual debs can certainly be downloaded [18:12] ahasenack: o.k., it's late here, will test tomorrow [18:13] np [18:13] if you don't mind, I'll add your links (logs) to the bug [18:13] sure, just note that they'll expire after 30 days, so copy anything you want to keep for longer [18:24] ah, reproduced it [18:24] cool, that makes it all simpler