Ok, phew, my test was incorrect, the bug is present in jammy. That makes this SRU simpler. I'll proceed with it, without a block-proposed tag.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [Test Plan] * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. * if other testing is appropriate to perform before landing this update, this should also be described here. [Where problems could occur] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [Original Description] <rbasak> ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. <rbasak> But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. <rbasak> AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). <ahasenack> I think the lp builders are using the focal hwe kernel <ahasenack> 5.4.0-something <ahasenack> let me check that build log <rbasak> But then something changed that caused this current FTBFS, and I haven't tracked down what that is. <ahasenack> hm, both are 10.6.7 <ahasenack> release and proposed <rbasak> What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? <rbasak> So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. <ahasenack> this is the current failure <ahasenack> 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) <ahasenack> and ulimit -l confirms that the limit is lower <ahasenack> Max locked memory 65536 65536 bytes <ahasenack> just 64kbytes <rbasak> Yeah but then how did the release pocket build work? <ahasenack> either the limit was different back then <ahasenack> or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
