[09:06] <seb128> vorlon, network-manager is blocked in proposed due to missing wpasupplicant on i386, do you have an opinion on what's the best resolution for that one?
[09:07] <seb128> vorlon, also that depends isn't new, did we delete binaries that had rdepends in the release pocket?
[09:08] <seb128> and do we have a report of things that in a such buggy state today?
[09:18] <Laney> xnox: have you seen the livefs build failures?
[09:21] <xnox> Laney:  not yet... which ones? desktop?
[09:22] <Laney> yup
[09:22] <Laney> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/focal/ubuntu/
[09:23] <xnox> No kernel output for oem! ?!
[09:26] <xnox> aha
[09:26] <xnox> Laney:  Wimpress: apw: seems like we don't have a real linux-oem in focal any more, replaced by dummy transitional package pointing at ga kernel.
[09:26] <xnox> Description: Depends on the generic kernel image and headers (dummy transitional packages)
[09:27] <xnox> apw:  what should I be installing in the focal builds to get a real linux-oem kernel? or does that not exist yet for v5.4?
[09:27] <xnox> ah
[09:27] <xnox> i think i need linux-oem-20.04 but it's not in focal-release yet
[09:28] <xnox> Laney:  i guess i should drop installing oem kernel for now?!
[09:28] <tjaalton> right, should be in proposed still
[09:32] <jibel> xnox, there is a similar problem on flavors too with signed kernel
[09:32] <jibel> E: Unable to locate package linux-signed-generic
[09:32] <xnox> tjaalton:  are all autopkgtests need retrying? i've retried just the linux-oem-5.4 itself, to see if it will work or not.
[09:33] <Laney> yeah maybe we can get it to move out to the release and then use that
[09:33] <xnox> tjaalton:  or does the kernel team adt matrix / triggers need to learn about new metapackages -> flavour mappings?
[09:33] <xnox> Laney:  but it is sad that images are broken.
[09:33] <Laney> it is
[09:35] <xnox> tjaalton:  apw: in the autopkgtests, setup commands are trying to install --setup-commands 'apt-get install -y linux-image-oem-5.4 linux-headers-oem-5.4 || apt-get install -y linux-image-generic-oem-5.4 linux-headers-generic-oem-5.4'
[09:35] <xnox> which is wrong, as it should be linux-image-oem-20.04
[09:35] <xnox> however i am guessing that autopkgtest code is not smart enough to do that.
[09:35] <tjaalton> xnox: there's something wrong with the seed
[09:35] <tjaalton> teething problems
[09:36] <xnox> tjaalton:  we do have something special in autopkgtest code when "linux-meta*" is a trigger
[09:37] <Laney> it comes from here https://git.launchpad.net/autopkgtest-cloud/tree/worker/worker#n460
[09:45] <xnox> ooh oooh
[09:45] <xnox> Laney:  we want the same ubuntu_versions treatment for -oem just like for -hwe
[09:45] <tjaalton> yes
[09:48] <Laney> usually someone (one specific someone) from the kernel team gives merge requests to make that block do the right thing :-)
[09:49] <tjaalton> nick starts with an a, ends with a w? :P
[09:50] <Laney> yes indeed
[09:50] <Laney> but anyone who understands it could do it I guess, and I will review that
[09:52] <tjaalton> I wonder if the focal master kernel needs some adjustment as well
[09:52] <tjaalton> at least adt test matrix isn't happy
[09:53] <tjaalton> though the binary names haven't changed there aiui
[09:53] <tjaalton> so maybe not
[09:54] <tjaalton> anyway, how to send a merge req?
[09:54] <tjaalton> or just a diff?
[09:55] <Laney> https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+ref/master
[09:55] <xnox> tjaalton:  it's autopkgtest-cloud project, git clone lp:autopkgtest-cloud & submit lp pr?
[09:55] <Laney> should be MRable as normal
[09:55] <tjaalton> or just copy the block about hwe and replace hwe/oem
[10:00] <tjaalton> though it can't break the earlier oem kernel testing, mmh..
[10:12] <tjaalton> seems I've never done a merge req on lp
[10:13] <tjaalton> pushed mine to lp, now what?
[10:17] <Laney> haha
[10:18] <Laney> just give me a link to the branch, I'll have a look
[10:18] <tjaalton> https://code.launchpad.net/~tjaalton/+git/autopkgtest-cloud/+ref/fix-oem
[10:19] <tjaalton> selecting propose for merging there and giving the master info it just says they can't be merged
[10:19] <tjaalton> the doc says the ui is rough, that's all..
[10:22] <Laney> don't worry about it
[10:24] <Laney> tjaalton: do we have to worry about oem-osp1?
[10:25] <tjaalton> gah :)
[10:25] <tjaalton> flavor.startswith('-oem-5'): :P
[10:26] <tjaalton> osp1 is dead in 6mo
[10:26] <Laney> also wait
[10:26] <Laney> this is going to result in linux-image-oem-20.04-5.4 isn't it?
[10:28] <tjaalton> how?
[10:28] <Laney> flavor is '-oem-5.4'
[10:28] <tjaalton> yes
[10:29] <tjaalton> oh
[10:29] <Laney> In [1]: '-oem-5.4'.replace('-oem-', '-oem-' + '20.04', 1)
[10:29] <Laney> Out[1]: '-oem-20.045.4'
[10:32] <tjaalton> right..
[10:34] <Laney> wouldn't "flavor = '-oem-{}'.format(ubuntu_release)" be right? (I'm not completely sure on the naming scheme, so take that with a pinch of salt)
[10:36] <tjaalton> how did you try it the last time?
[10:37] <Laney> I've not, was just reading the code
[10:37] <Laney> sadly there is no testsuite
[10:37] <tjaalton> the in/out thing? wrote it by hand? :P
[10:37] <Laney> that is ipython
[10:38] <tjaalton> ah
[10:38] <Laney> but yes I wrote the first line myself :(
[10:41] <tjaalton> anyway, your suggestion should be right
[10:59] <tjaalton> Laney: pushed a new version
[11:08]  * Laney looks
[11:54] <tjaalton> Laney: what's the verdict?
[12:09] <Laney> tjaalton: Had to fix up startwith() since it doesn't accept a regex, but it's running there now
[12:09] <Laney> just doing a test run
[12:09] <tjaalton> oh cool
[12:10] <Laney> http://autopkgtest.ubuntu.com/running#pkg-adv-17v35x
[12:12] <Laney> that seemed to work
[12:13] <Laney> I will retry the rest of them now
[12:15] <tjaalton> great
[12:16] <Laney> after these tests results, what else is needed to migrate this kernel?
[12:20] <tjaalton> I think that's it
[12:20] <tjaalton> but not sure
[12:21] <Laney> it's really only the block from ap_w
[12:22] <Laney> and the tag on bug #1858633
[12:22] <ubottu> bug 1858633 in Kernel SRU Workflow regression-testing "focal/linux-oem-5.4: 5.4.0-1001.2 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1858633
[12:22] <Laney> so some workflow stuff I guess
[12:23] <tjaalton> yeah
[12:24] <Laney> well, if it could go in, we could unbreak desktop isos which would be nice
[12:30] <tjaalton> sure thing
[12:38] <doko> LocutusOfBorg: do you remember why the python-ddt binary package had to be kept?
[12:56] <doko> coreycb: could you have a look at https://launchpad.net/ubuntu/+source/python-formencode/1.3.0-3ubuntu2/+build/18265750 ? Debian has dropped that b-d
[13:15] <cpaelzer> kanashiro: nut MP is good, can you upload it already or should I?
[13:15] <coreycb> doko: sure, will do. sorry been side tracked on non distro things but hopefully can look today.
[13:20] <LocutusOfBorg> doko reverse-depends -b python-ddt -r eoan
[13:21] <LocutusOfBorg> would say, not anymore
[13:21]  * LocutusOfBorg uploads
[13:23] <LocutusOfBorg> thanks
=== ricab is now known as ricab|lunch
[14:29] <ahasenack> cpaelzer: are you aware of "prior art" in amending an apparmor profile just for a test suite? dep8
[14:29] <cpaelzer> you mean at test time?
[14:30] <ahasenack> the test is run in a temporary directory, so I'm thinking in adding a rule to /etc/apparmor.d/local/<profile> at test time
[14:30] <cpaelzer> start test, change + reload profile, test
[14:30] <ahasenack> yeah
[14:30] <ahasenack> in this case, as soon as I know the tmpdir name
[14:30] <cpaelzer> ahasenack: does the package in question even include a local override?
[14:30] <ahasenack> no
[14:30] <cpaelzer> ha :-)
[14:30] <ahasenack> the profile is for another package
[14:30] <cpaelzer> but does that one have a local include
[14:31] <cpaelzer> that isn't always the case, hence I'm asking
[14:31] <ahasenack> it's a package that uses openldap, and runs an openldap server elsewhere where apparmor doesn't like it, just for the test
[14:31] <cpaelzer> I know of no prior art in dep8 tests
[14:31] <ahasenack> so the openldap profile doesn't like to have the openldap daemon storing its database and config files in /tmp/tmpXXXX
[14:31] <cpaelzer> but I've done that manually often for testing
[14:31] <ahasenack> the other option is to disable apparmor
[14:31] <cpaelzer> check out https://help.ubuntu.com/community/AppArmor#Reload_one_profile
[14:31] <ahasenack> for the test
[14:32] <cpaelzer> and modify the profile as needed wither via a /etc/apparmor.d/local/<profile> if it has an include or just the main profile (it is an ephemeral test env after all)
[14:32] <Laney> you probably want Restrictions: breaks-testbed for that though :-)
[14:32] <ahasenack> I would create the local override, it's meant for things like these after all (local customizations)
[14:33] <ahasenack> the include for local/<profile> is always there
[14:33] <cpaelzer> ahasenack: ok if it has the include do it and add the Restriction Laney mentioned
[14:35] <ahasenack> noted
[14:35] <Laney> (and needs-root if you want to write to /etc)
[14:36] <ahasenack> indeed
[14:38] <ahasenack> <cpaelzer> ahasenack: does the package in question even include a local override?
[14:38] <ahasenack> I thought you meant if a local override file was already shipped with the package
[14:38] <cpaelzer> ahasenack: that would be done by dh-apparmor in most cases
[14:38] <ahasenack> our profiles all seem to end with an include, "just in casE"
[14:38] <cpaelzer> ahasenack: but the main profile needs to have the include statement
[14:38] <ahasenack>   # Site-specific additions and overrides. See local/README for details.
[14:38] <ahasenack>   #include <local/usr.sbin.slapd>
[14:38] <ahasenack> }
[14:38] <cpaelzer> ahasenack: yeah then this is fine, but not true for all packages
[14:39] <ahasenack> ok
[14:39] <ahasenack> it's confusing that # can also indicate a comment :/
[14:39] <ahasenack> sometimes people have weird ideas about configuration file syntax
[14:46] <kanashiro> cpaelzer, I still do not have upload rights, could you please sponsor nut for me? I'll follow its migration towards the release pocket
[14:56] <cpaelzer> kanashiro: done
[14:57] <ahasenack> weird that only the amd64 build complained about  sbuild-build-depends-krb5-dummy : Depends: python but it is not going to be installed (https://launchpad.net/ubuntu/+source/krb5/1.17-6ubuntu1)
[14:57] <ahasenack> anyway, I was able to switch that to py3
[14:58] <cpaelzer> ahasenack: could it have been the arch-indep portion - that usually runs only on amd64
[14:58] <ahasenack> ah, yes, it's arch-indep
[15:00] <doko> jamespage: ubuntu-only, packaged by yourself: https://launchpad.net/ubuntu/+source/radosgw-agent/1.2.7-0ubuntu2/+build/18265504
[15:02] <seb128> rbasak, hey, could you review the pulseaudio/eoan SRU? it's a simple fix for a problem that got quite some users heat (sound output often switching to the hdmi output when not wanted)
=== ricab|lunch is now known as ricab
[15:07] <rbasak> Looking
[15:07] <kanashiro> cpaelzer, thanks!
[15:08] <doko> xnox: https://launchpadlibrarian.net/456873774/buildlog_ubuntu-focal-amd64.regina-normal_5.1-6build1_BUILDING.txt.gz  some boost/python2 fallout
[15:08] <rbasak> seb128: is there any possibility of upsetting users relying on the current behaviour?
[15:09]  * rbasak continues reading
[15:09] <seb128> rbasak, that's always an option, but the behaviour only changed in 19.10 and is the main complain we get about 19.10 atm
[15:09] <seb128> we might piss off a few users but the ration should be in favor of the fix
[15:10] <seb128> option->possibility
[15:12] <rbasak> seb128: OK that sounds reasonable. But could you document that in Regression Potential please? I've just finished reading the bug, reviewing the patch now.
[15:15] <seb128> rbasak, description updated
[15:18] <rbasak> Looks good, thanks!
[15:19] <rbasak> Accepted
[15:24] <seb128> rbasak, thanks!
[16:02] <vorlon> seb128: we should drop the network-manager binary package on i386, since we only really want the libraries and no one will ever install network-manager/i386.  This is reported as an uninstallable in the release pocket here: https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt and it was on my list to look at today, but if Desktop wanted to get to it first, I'd refer to
[16:02] <vorlon> libkate as the best reference implementation
[16:05] <seb128> vorlon, I plan to merge/update n-m tomorrow, I can look at dropping the i386 binary while I'm at it
[16:22] <mitya57> doko: https://launchpad.net/ubuntu/+source/python-docutils/0.15.2+dfsg-2ubuntu2
[16:22] <mitya57> In Debian I will replace python with python3 rather than python2, but I want to wait for the next release first (which is expected soon).
[16:24] <doko> ta
[16:54] <doko> xnox: https://launchpad.net/ubuntu/+source/android-tools/5.1.1.r38-1.1ubuntu1   you seem to be involved in Debian too. what's the way forward?
[16:57] <ahasenack> rbasak: is this something you still want to drive for 20.04? https://bugs.launchpad.net/ubuntu/+source/squid/+bug/1780341
[16:57] <ubottu> Launchpad bug 1780341 in squid (Ubuntu) "squid should default to more human friendly timestamps" [Undecided,In progress]
[16:57] <rbasak> ahasenack: I would like it to happen, but it fell down the list :(
[16:58] <rbasak> I should unassign myself
[16:58] <ahasenack> yeah, I just saw it because I was about to open a new bug in squid, and saw the list of open bugs
[17:47] <xnox> doko:  urgh
[17:52] <jamespage> doko: that can be RM'ed as well - its superceeded by functionality in ceph radosgw
[17:56] <doko> jamespage: to make sure, you're talking about radosgw-agent?