[06:33] pulseaudio is not building on eoan [06:33] 33%: Checks: 3, Failures: 2, Errors: 0 [06:33] tests/cpu-volume-test.c:81:F:svolume:svolume_mmx_test:0: Failed [06:33] tests/cpu-volume-test.c:81:F:svolume:svolume_sse_test:0: Failed [06:33] FAIL cpu-volume-test (exit status: 1) [06:34] Also I miss you folks... This is what I've been busy with lately... https://lkml.org/lkml/2019/7/23/673 [08:37] oSoMoN: hi. does the libreoffice smoketest fail here against kconfig look an issue to you, or just a random glitch? http://autopkgtest.ubuntu.com/packages/libr/libreoffice/eoan/armhf [08:38] I am retrying, but will a long while to get result of that [08:39] RikMills, that's a question for marcustomlinson ^ [08:39] RikMills, marcustomlinson is the new libreoffice maintainer [08:39] lol, sorry oSoMoN :) [08:39] oh, sorry. I must have missed that change! [08:41] RikMills: hey, looks random to me. At least, I haven't seen that before [08:42] marcustomlinson: ok. thanks. I won't spend any more time looking then, and just see what result of the test retry is [08:43] marcustomlinson, speaking about libreoffice, do you have an eoan upload coming? I want to update poppler before ff, as usual that inludes a soname change and require to rebuild (and often adjust) rdepends including libreoffice [08:44] seb128: yes 6.3.0 needs to be uploaded soon. I'm running autopkgtests now on the build in my ppa, if all is well I should have it in today. but... that may be hopeful [08:44] marcustomlinson, I will probably try to do that transition next week, I will put poppler first in a ppa and kick a no change rebuild there to see if libreoffice needs changes but I just wanted to give you some forward notice [08:44] marcustomlinson, k, feels like we should get 6.3 in before, which is better [08:45] it means I'm not public the update and it gives a newer version to test which has more chance to work with the current poppler :) [08:45] seb128: yeah I aim to have it uploaded soon soon. Worst case Mon/Tues [08:46] marcustomlinson, k, good, well let's talk again next week then, hopefully by then 6.3 is in eoan and I've test build results === LocutusOfBorg is now known as mdelaus === mdelaus is now known as Locutusofborg [10:34] marcustomlinson, hi, could push your current ubuntu-eoan-6.3 branch, so I can take a look? [10:35] *could you [10:35] ricotz: WIP at the moment [10:35] ricotz: will push sometime today, I'll ping you, sorry [10:35] marcustomlinson, I know the current one look like WIP already, you can force-push it later [10:38] marcustomlinson, e.g. the nss tarball can be filtered out [11:02] ricotz: ok I've pushed. You'll see I'm pretty aggressively trying to reduce diff between Debian and Ubuntu [11:04] ricotz: it builds as is, but I got a few weird autopkgtest failures on armhf I'm still looking at [11:09] marcustomlinson, oh dear [11:10] marcustomlinson, this is aggressive indeed, at least merge the revert and apply to preserve the history for those changes [11:11] marcustomlinson, did you confirm with infra that all builders provide the required diskspace? e.g. like 50G [11:11] ricotz: as I said it is building [11:12] https://launchpad.net/~marcustomlinson/+archive/ubuntu/libreoffice/+packages [11:12] ok, but this is not what I asked [11:12] the split was made to deal with launchpad's deficiencies [11:13] yeah legacy deficiencies [11:14] All builders have 60G of disk [11:15] marcustomlinson, please squash revert and reapply [11:15] cjwatson, this sounds sufficient at this point [11:15] ok [11:16] marcustomlinson, could you rebase on libreoffice_6.3.0-1 tag [11:16] I mean "merge" [11:17] sorry, need to go and will be back in a few hours [12:23] src:magnus isn't autosyncing [12:23] No mention in the log and it's not blacklisted [12:23] However it previously existed in Debian with a higher version string [12:23] Launchpad has it in publishing history with that. This might explain it. [12:24] Is a manual sync acceptable, or would that fail due to the version? [12:24] Is it correct in Debian for the version to have gone backwards, or should it have an epoch bump in Debian? [12:26] rbasak: I'd say it's OK to not have an epoch because it was not part of a stable release anymore, so no upgrades broke [12:26] but I mean you can always ask for an epoch [12:28] rbasak: FWIW, syncpackage does not do anything [12:28] wonder if uploading the dsc does === ricab is now known as ricab|lunch [12:34] Ah no the sync went through [12:45] rbasak: do you know if backportpackage is broken with openstack-dev-tools 0.170? i could very possibly be mis-using it but the new signature checking is failing to verify signatures on .dsc files. [12:49] I don't know about that, sorry [12:51] rbasak: ok i'll check with mattia === ricab|lunch is now known as ricab [14:12] after the featurefreeze (22nd august) how hard is it to continue importing leaf packages? or is that the last date? [14:27] tarzeau: feature change uploads require an exception from the release team [14:27] tarzeau: https://wiki.ubuntu.com/FeatureFreeze [14:28] tarzeau: and https://wiki.ubuntu.com/FreezeExceptionProcess [14:32] rbasak: ok thanks [15:06] bryce has the PHP transition ready [15:06] The MySQL 8.0 transition is still in progress. [15:06] Any implications for entangling them intentionally, apart from that we'll need both PHP related and MySQL related FTBFS fixed before both can migrate? [15:07] Since feature freeze is coming up, delaying PHP doesn't seem like a great idea. [15:07] bryce already has all FTBFS resolved in a trial PPA [15:07] And most (but not all) FTBFS are resolved in a trial MySQL 8 transition PPA too. [15:07] https://launchpad.net/~bryce/+archive/ubuntu/php7.3-transition.4/+packages [15:25] vorlon: ^ advice please? Can you see any issues with going for both transitions at once? [15:36] rbasak, I have one [15:37] mythtv is entangling libvpx and mysql-8.0 [15:38] if anybody can kick it out to proposed for some days... we can at least have libvpx migrate [15:38] Locutusofborg: kick what out to proposed [15:38] ? [15:38] mythtv [15:38] so they are not entangled anymore [15:38] vpx and mysql [15:39] fixing xpra will make vpx migrate [15:39] I'm not sure I follow [15:40] But anyway, I'm fine with it as long as we don't hold up progress on MySQL or PHP :) [15:42] vorlon, please please please kick deal.ii out from arm64 [15:43] so we can make slepc/petsc/hypre/ufl/sundials/mshr/ffc/fenix/dolfin/dijitso transition migrate [15:43] it fails, I tried old gcc, still fails [15:44] will be fixed in Debian by ginggs eventually, in debian fails on ppc64el [16:23] rbasak: the risk of letting mysql and php transitions get entangled is random other uploads of leaf packages resetting the transition; the risk of this is higher the more such leaf packages there are. I think you will find it better to finish the mysql transition first [16:23] Locutusofborg: so deal.ii is broken on arm64 in Ubuntu but not in Debian? [17:06] vorlon: yes, deal.ii FTBFS on arm64 with gcc9, builds in debian where gcc8 is still default [17:17] vorlon: is there any chance we can stick with python3-django 1:1.11.22-1 and sync 2:2.2.4-1 next cycle? upstream openstack doesn't plan to add any django 2.2 support until next cycle. [17:54] ginggs: so has anyone tried building deal.ii with gcc-8 in Ubuntu to work around this? [17:56] coreycb: django 2:2.2.4-1 is currently stalled in eoan-proposed and will stay there until all the packages which depend on it are happy with the new version, so I think you're fine [17:56] coreycb: also, at present there's a pile of unresolved autopkgtest regressions for the reverse-dependencies [17:57] vorlon: ok thanks [20:55] vorlon: Locutusofborg is trying here https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10402252/+listing-archive-extra [21:20] vorlon, I failed... [21:20] lets see if gfortran is to blame