[06:44] <vorlon> Eickmeyer: you'll need to pick up the changes from ubuntustudio-default-settings 0.74ubuntu1 that was uploaded by doko
[07:25] <LocutusOfBorg> kanashiro, hello, thanks for the ppa upload, but I was meaning "from the next one" :) I don't care about binaries, because copying them from ppa is forbidden, I care about sources and diffs :D
[07:25] <LocutusOfBorg> and also, it might be even easier for you to upload it instead of opening a bug each time
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.9-1]
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.9-1]
[09:14] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.9-1]
[09:22] <doko> bryce: is it still planned to remove php7.3 in focal? in this case I'm suggestion to just ignore the failed autopkg tests triggered by php7.3, which are also run by php7.4
[09:30] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.57 => 2.408.58] (desktop-core)
[09:37] <vorlon> doko: fwiw I pinged bryce in another channel about this as well, and I've set the skiptest hint now, as there should be plenty of time for him to object today before the icu transition is actually going to go through
[10:15] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (eoan-proposed) [1.9+19.10ubuntu1]
[10:18] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.58]
[10:23] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (bionic-proposed) [1.9+18.04ubuntu1]
[10:26] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.9+16.04ubuntu1]
[11:24] <kanashiro> locutus_, ack :)
[12:38] <ahasenack> hi release team, bind9 and bind9-libs are stuck because of the kernel (https://launchpad.net/bugs/1865025), via debian-installer. Is this something we could migrate manually, since debian-installer isn't used in a live system, or is that worse?
[12:51] <vorlon> ahasenack: well it would break buildability of the classic server ISOs, and I expect it would break netboot images as well
[12:51] <ahasenack> ok :(
[12:52] <ahasenack> I'm just anxious that these big bind9 changes haven't seen "real world" use yet
[12:58] <cpaelzer> hiho, I know someone has done it in the past for openstack test cases but I forgot the buzzwords to search for. I'm looking for how to mark a test as huge.
[12:58] <ahasenack> I know, I know!
[12:58] <cpaelzer> tel lme please
[12:58] <cpaelzer> as I have debugged a case in our proposed migration down to a OOM
[12:58] <ahasenack> I have to check my swap file, just a moment
[12:59]  * cpaelzer is eagerly waiting for ahasenack to come back with his notes
[12:59] <ahasenack> have to do some sleuthing, it all started with a hint branch
[12:59] <cpaelzer> ok that seems to be the natural place
[12:59] <ahasenack> cpaelzer: https://code.launchpad.net/~ahasenack/britney/hint-mysql8-arm64/+merge/379582
[13:00] <ahasenack> cpaelzer: check steve's response, and mine
[13:00] <ahasenack> cpaelzer: oh, and https://code.launchpad.net/~ahasenack/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/379592 for a direct route
[13:01] <cpaelzer> yeah and I see nova in the list as I remembered :-)
[13:01] <cpaelzer> thanks a lot ahasenack
[13:02] <cpaelzer> that is for python-cffi which is blocking python3-defaults so I guess people will be happy
[13:03] <cpaelzer> there will soon be an MP and more details in my proposed migration status mail ...
[13:03] <cpaelzer> ahasenack: look at the dir I already found this repo ~/work/britney/autopkgtest-cloud :-)
[13:03] <cpaelzer> makes sense
[13:04] <ahasenack> we organize our directories per the solution, not the problem :)
[13:04] <ahasenack> oh, this autopkgtest-cloud should have been in the "what I learned" column of our retrospective
[13:04] <cpaelzer> ahasenack: yeah
[13:04] <cpaelzer> especially since over the last two years I now learned it thrice I think
[13:18] <cpaelzer> ahasenack: here is it https://code.launchpad.net/~paelzer/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/380362
[13:18] <cpaelzer> actually vorlon if you are still around you might want to look at this MP ^^
[13:18] <cpaelzer> I saw you re-ran python-cffi tests as well
[13:33] <vorlon> cpaelzer: so the tests are running out of memory?
[13:54] <vorlon> cpaelzer: merged and deployed; feel free to retry the tests now
[14:00] <Mirv> I have a vague memory that getting MIR approved source package's binary package to main did not involve formal process and I could ask here?
[14:01] <Mirv> Could I get libenchant-2-voikko into main? I've added it to language-selector at https://launchpad.net/ubuntu/+source/language-selector/0.201 but it's not getting installed by default presumably due to it being still in universe.
[14:03] <Mirv> (yes, found at 1859601 that binaries don't generally have to go through MIR process)
[14:04] <Mirv> didrocks: ^ maybe you can help with that if you happen to be around, or then I'll just wait and ping someone next week
[14:05] <vorlon> Mirv: it isn't showing up as a mismatch on https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed
[14:06] <Mirv> vorlon: right, that's another topic - if it's only language selector that is pulling it in, it's not showing as package dependency problem
[14:07] <vorlon> Mirv: is there a seed that things referenced by language-selector are normally added to?
[14:08] <vorlon> libenchant-voikko is in the supported seed
[14:08] <vorlon> so I guess it needs adding there?
[14:10] <Mirv> right, seeds, those I had forgotten about. correct, then. I see if I can do a MR.
[14:11] <vorlon> and should libenchant-voikko be dropped, in favor of libenchant-2-voikko?  is this a swap?
[14:16] <Mirv> the transition isn't 100% complete, enchant 1 is still in default installation, so maybe not for 20.04 yet
[14:18] <vorlon> Mirv: so in what cases is language-selector installing -2- instead of libenchant-voikko?
[14:22] <Mirv> I'm trying to update myself on this topic.. it seems my installation was outdated. It seems default installation no longer installs enchant 1, but eg abiword does want it. Enchant 1 is in main, but maybe nothing in main depends on it anymore.. but this goes a bit out of voikko topic.
[14:23] <Mirv> vorlon: It's currently trying to install plugins for both enchant 2 and enchant 1. I think it'd be alright if enchant 1 would not be automatically installed during installation, but suggested after installation by Language Support when universe repo is enabled.
[14:23] <Mirv> (in the case Enchant 1 would be demoted to universe)
[14:24] <Mirv> That would mean I could both add -2- to seeds and remove the version 1 from there, as the latter is a useful package but not required in default installation.
[14:24]  * vorlon nods
[14:31] <Mirv> ok done the change add https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=6901c478d792124c2fe3cf2289daac94ec245644 - please review, I feel shaky at using my superpowers which I don't do daily these days
[14:32] <vorlon> Mirv: lgtm
[14:48] -queuebot:#ubuntu-release- Unapproved: accepted crash [source] (bionic-proposed) [7.2.8-1ubuntu0.18.04.1]
[14:59] <Eickmeyer> vorlon, doko: Ok, then please reject 0.76 hanging around in proposed.
[15:01] <Eickmeyer> doko: To answer your question, I was unaware you did anything because we do everything using git, and there were no changes there.
[15:09] <cpaelzer> thanks vorlon, I re-scheduled the tests that formerly failed
[15:09] <cpaelzer> will check somewhen later if they succeed now as intended
[15:15] <Eickmeyer> vorlon: nm, I guess it'll just supercede anyhow.
[16:56] <wxl> there's some weird stuff going on with our lubuntu daily. should i just assume this is some sort of blip and restart? https://launchpadlibrarian.net/468001105/buildlog_ubuntu_focal_amd64_lubuntu_BUILDING.txt.gz similar issue in budgie btw https://launchpadlibrarian.net/467987391/buildlog_ubuntu_focal_amd64_ubuntu-budgie_BUILDING.txt.gz
[16:57] <RikMills> some kubuntu 20.04 users have reported the same error. looks like the last plymouth upload
[16:58] <wxl> on upgrade?
[16:58] <RikMills> yes, they pasted this error https://paste.ubuntu.com/p/wDSsdSh2YQ/
[16:58] <RikMills> I'm going to update a VM to see shortly
[17:01] <wxl> looks like that file was added here https://launchpadlibrarian.net/467954305/plymouth_0.9.4git20200109-0ubuntu3.3_0.9.4git20200109-0ubuntu5.diff.gz
[17:02] <RikMills> wxl: I get this: https://i.imgur.com/hK2eEFX.png
[17:02] <wxl> looks similar
[17:02] <RikMills> looks like seb128 has already logged off IRC for the day
[17:07] <wxl> that file most definitely does not exist
[17:10] <RikMills> I guess it wouldn't, as a flavour would not have the ubuntu log plymouth theme installed
[17:10] <RikMills> *log
[17:10] <RikMills> *logo
[17:10] <RikMills> ffs
[17:11]  * RikMills blames new keyboard....
[17:11] <wxl> no, i mean that image does not exist in the package
[17:11] <wxl> so we added a reference in rules to install a file that doesn't exist
[17:11] <wxl> that change should really be reverted until someone can actually add the right image XD
[17:11] <franksmcb> RikMills we are seeing that plymouth error in Ubuntu MATE
[17:16] <RikMills> there is a /usr/share/plymouth/themes/spinner/watermark.png installed by the plymouth deb
[17:18] <franksmcb> https://bugs.launchpad.net/ubuntu-mate/+bug/1866377
[17:18] <wxl> that's the problem file RikMills
[17:38] <RikMills> wxl: I think it is more that the target dir of the copy command does not exist?
[17:39] <wxl> it's the file itself
[17:39] <RikMills> no
[17:40] <wxl> ??
[17:41] <RikMills> wxl: cp /usr/share/plymouth/ubuntu-logo.png "${DESTDIR}/usr/share/plymouth/themes/spinner/watermark.png"
[17:42] <RikMills> ubuntu-logo.png exists
[17:42] <RikMills> if ${DESTDIR}/usr/share/plymouth/themes/spinner/ does not exist, you would get the error in the upgrade
[17:43] <wxl> oh derp i didn't read that right
[17:48] <wxl> you're right RikMills it's the target dir
[18:27] <cpaelzer> vorlon: python-cffi now passed on all arches - no more blocking itself and python3-defaults
[18:27] <cpaelzer> just FYI, thank for merging the big_packages MP
[18:46] <tumbleweed> cpaelzer: how did you get it passing?
[19:02] <ginggs> tumbleweed: https://git.launchpad.net/autopkgtest-cloud/commit/?id=c47f5e879fa836425d950053b6bf128598591527
[19:03] <tumbleweed> aha, thanks
[19:03] <tumbleweed> I *knew* it had to be something infra...
[19:03] <tumbleweed> not sure what test is that huge, though
[19:27] <Eickmeyer> RikMills, wxl: Same with Ubuntu Studio. ISO FTB.
[19:39] <kanashiro> hi, chef and some related packages were removed from Debian testing as per maintainer request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952792
[19:39] <kanashiro> we also have some issues with chef and ruby 2.7
[19:39] <kanashiro> should we follow Debian and remove them as well?
[19:47] <tumbleweed> yes
[19:49] <bryce> doko yep removing 7.3 is the plan, and do feel free to skip anything as needed to resolve icu, I suspect getting that transition completed is a much higher priority.
[19:51] <doko> bryce: it would be nice if yould look the php-horde-* test failures triggered by php7.4
[19:52] <ahasenack> "yould" "you could"? :)
[19:52] <kanashiro> I just talked one of the chef maintainers in Debian and he said that he will try to fix it this weekend, let's wait until Monday and if he has those packages fixed I'll request a FFe
[19:52] <doko> late here ... sprint finished ;p
[19:52] <bryce> doko, yep it's on our list, cpaelzer had looked at them a couple days ago
[19:53] <bryce> for some reason those didn't show up on the ben-generated report, nor in the excuses page but I remembered they were problems with php7.2->7.3
[21:14] <doko> Unpacking libc6:amd64 (2.31-0ubuntu1) over (2.30-0ubuntu3) ...
[21:14] <doko> Setting up libc6:amd64 (2.31-0ubuntu1) ...
[21:14] <doko> /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
[21:14] <doko> dpkg: error processing package libc6:amd64 (--configure):
[21:14] <doko>  installed libc6:amd64 package post-installation script subprocess returned error exit status 127
[21:14] <doko> Errors were encountered while processing:
[21:14] <doko>  libc6:amd64
[21:14] <doko> E: Sub-process /usr/bin/dpkg returned an error code (1)
[21:21] <doko> vorlon: so every autopkg test fails now, and there's nothing that pulls in libcrypt1
[21:22] <doko> I assume we can cancel almost all running autopkg tests
[21:26] <juliank> doko: sounds like libc6 must predepend on libcrypt1
[21:26] <juliank> or depends, i'm not sure
[21:32] <doko> I uploaded perl to pick up that dependency, but getting all those tests passing quicky doesn't seem to be possible, so I'm uploading base-files to depend on libcrypt1, planning to copy that to the release pocket
[21:33] <doko> juliank: it has the dependency, but almost all autopkg tests are picking up the glibc from the release pocket
[21:34] <juliank> doko: I don't understand, glibc in release pocket ships libcrypto1, so that should be fine; and if libc6 from proposed depends on libcrypto1 it should be fine too
[21:36] <doko> hmm
[21:37] <doko> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/3/389-ds-base/20200306_162651_f9385@/log.gz
[21:37] <doko> it unpacks libcrypt1 before updating libc6
[21:38] <juliank> doko: right, but it might need running ldconfig between those steps to make it pick it up in the ld.so cache
[21:39] <doko> just wondering why that wasn't see in unstaböe
[21:39] <doko> seen even
[21:39] <juliank> doko: so libcrypt1 needs to be configured before libc6, aka libc6 needs to pre-depend on libcrypto1 (or run ldconfig in its preinst)
[21:39] <juliank> running ldconfig in the preinst should be easier
[21:40] <juliank> it at least avoids a pre-depends at the bottom layer of the dependency tree
[21:41] <juliank> doko: oh but it is configured
[21:44] <juliank> doko: oh, but the ldconfig call is done by triggers, it probably has not been executed at that point?
[21:45] <juliank> anyway, seems a bit odd
[21:45] <doko> yep, but why doesn't it fail in unstable? I was looking for some version tests which I didn't update, but can't find anything
[21:46] <juliank> i don't really know
[21:50] <doko> something to investigate before the release ...
[21:55] <juliank> doko: I played around locally, upgrading libc6 (which instlaled libcrypt1), and it configured fine
[21:55] <juliank> so ... confused
[22:07] <doko> libxcrypt should never have migrated to the release pocket with the wrong breaks/replaces, but it was a debian sync :-/
[22:14] <doko> juliank: so calling ldconfig in the preinst unconditionally sounds like an appropriate fix, when updating to the current version. but not now. I'll look at that tomorrow again
[22:15] <juliank> doko: not unconditionally, but on first upgrade to version depending on libcrypt1 should be ok
[22:15] <juliank> But maybe you meant that
[22:15] <doko> yep, that's what I mean
[22:15] <juliank> Ok
[22:15] <juliank> It's late
[22:24] <doko> the pre-depends wouldn't work with the current breaks/replaces in libcrypt1
[22:35] <doko> juliank: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/11045520/+listing-archive-extra  now building, will check tomorrow
[22:51] <xnox> doko:  and do just execute the ldconfig with LDCONFIG_NOTRIGGER=1 environment variable to actually force the ldconfig to happen.