Hi KiBI, > On 10 Feb 2018, at 10:52, Julien Cristau <jcris...@debian.org> wrote: > > Control: tag -1 moreinfo > > Hi Ondřej, > > On Mon, Dec 11, 2017 at 14:22:03 +0000, Ondřej Surý wrote: > >> this is stretch-pu for mariadb-10.1.29 upstream release and couple of >> fixes that creeped in stretch version just before freeze. >> >> Fixes: >> >> * #875708 - Add libconfig-inifiles-perl to mariadb-client-10.1 depends to >> fix mytop >> > ok > >> * Failing non-release archs were added to the list of architectures that are >> allowed >> to fail test >> > that doesn't sound necessary in stable? harmless though, so probably > ok. > >> * mips64el was added to a list of other mips* platforms allowed to fail the >> tests >> > That's a bit confusing, where did the mips64el binaries we do have come > from if tests are expected to fail?
mips and mipsel has been on this list since 2015 (10.0.23-1 debian release) as upstream doesn’t guarantee that the tests will pass on this platform, so the change just rectifies the situation after mips64el was added to the release architecture list. As a side note: There has been recent work to move the whole suite to the autopkgtest suite instead of running it as a part of build process, and fix any failing tests on non-major platforms in asynchronous manner. >> * I reverted upstream decision to use embedded pcre3 library as we >> need to fix #878107 and #876299 in jessie and stretch too >> > Is there a plan for doing this? I'm not seeing a pu request for pcre3. I already offered Matthew Vernon help with pcre3, but it’s not my place to request pu for other people packages. As far as I remember this affects only edge cases on edge architectures, but it was broken before anyway, so we are basically just keeping status quo. >> Upstream: >> >> * There's couple of minor security fixes that doesn't warrant security >> update, but it should be updated nevertheless (this this pu request). >> >> I'll send the debdiff in a reply to this email, so this message reaches the >> list. >> > I'm seeing quite a bunch of patch noise, including dropping patch > descriptions (and authorship), which seems less than helpful. Can we > please not? I switched to gbp pq for patch management as it makes it easier for me to manage the patches, but I can revert the most intrusive changes. Dropping the descriptions and authorship was not intended. Ondřej -- Ondřej Surý ond...@sury.org
