[10:17] <seb128> does anyone understand that build failure in cosmic?
[10:17] <seb128> https://launchpadlibrarian.net/385132372/buildlog_ubuntu-cosmic-arm64.gnome-control-center_1%3A3.29.90-1~ubuntu2_BUILDING.txt.gz
[10:17] <seb128> The following packages have unmet dependencies:
[10:17] <seb128>  sbuild-build-depends-gnome-control-center-dummy : Depends: locales but it is not going to be installed
[10:17] <seb128> but installing locales works in a pbuilder
[10:18] <Unit193> seb128: The one in -proposed?
[10:18] <Faux> locales has all kinds of weird conflict, you get that error for conflicts, right?
[10:18] <seb128> Unit193, it's an upload to cosmic so I guess it builds with proposed yes, but I've proposed enabled in my pbuilder as well
[10:19] <seb128> Faux, I get that error in a cosmic upload
[10:19] <Unit193> Ah good, and the latter was my question.
[10:23] <acheronuk> suceeded on amd64, i386 and armhf, but failed on arm64, ppc64el and s390x?
[10:23] <abeato> sil2100, hey, I see you merged the no-fakeroot PR, thanks. I have rebased https://github.com/CanonicalLtd/ubuntu-image/pull/155 , and was wondering on what you think about removal of /boot/grub. Would you be happy if I remove the contents of it instead?
[10:24] <seb128> acheronuk, doh, you are right, I though I saw it failing on all arches but indeed not
[10:24] <seb128> so yeah, I guess side effect from https://launchpad.net/ubuntu/+source/glibc/2.28-0ubuntu1
[10:25] <seb128> that was uploaded after ff without a ffe
[10:25] <seb128> :/
[10:25] <acheronuk> I would guess it is that
[10:26] <acheronuk> seb128: I have seen no freeze announcement yet, though schedule says it should be there. however, I did see at least one person suggest they might ask for it to be pushed back a week
[10:27] <seb128> ah, I wouldn't say no to that :)
[10:28] <sil2100> abeato: hey! I still need to re-review that and re-evaluate, might be that I'd be good with the change, or request just the content removal
[10:30] <abeato> sil2100, alright, will wait for that then, thanks
[12:21] <ahasenack> is it ok/correct for python3-numpy to pull in *both* python3.6 and python 3.7?
[12:21] <ahasenack> Depends: python3 (<< 3.8), python3 (>= 3.6~), python3.6:any, python3.7:any, python3:any (>= 3.3.2-2~), ...
[12:21] <ahasenack> that is making python3.7 available to other python modules on the system, modules which do not support 3.7 yet
[12:22] <ahasenack> for example, they use methods with "async" as a keyword argument
[12:22] <ahasenack> python3-libcloud is one such package
[12:23] <ahasenack> example: https://pastebin.ubuntu.com/p/Kn77DXfxR5/
[12:23] <ahasenack> works before installing python3-numpy, fails after
[12:23] <ahasenack> and it doesn't even use numpy
[14:38] <kyrofa> Hey slangasek, wanted to circle back on the inability to install snaps in armhf autopkgtests: mvo gave making it a work a valiant effort, but was unable to get snapd working in such a scenario (https://github.com/snapcore/snapd/pull/5621#issuecomment-415677092) . Do we have any alternatives regarding that lxc profile?
[14:40] <mvo> kyrofa: yeah, sorry, unless someone like Stéphane has new ideas I think we hit a wall
[14:43] <kyrofa> mvo, understood, I appreciate the effort :)
[16:50] <slangasek> kyrofa: my expectation was that the snapd team might tell us some other changes we should make to relax security in that container so that snapd does work... they are already privileged containers and it's not a concern for us to make them a little more privileged
[16:53] <cjwatson> slangasek: you might like to look at the collection of hacks that launchpad-buildd uses to make it work
[16:53] <cjwatson> those were based on discussions with Stéphane
[16:54] <cjwatson> search for raw_lxc_config
[17:29] <slangasek> kyrofa: what's the quickest way for me to test if snapd is happy with these profile changes?  I have snapd running but I think we got that far before; I'm now getting a failure contacting the snap store but I'm not sure if I've missed a proxy setting
[17:30] <kyrofa> slangasek, oh darn, you can't contact the store?
[17:30] <slangasek> kyrofa: at the moment; but the autopkgtest environment is meant to have networking, hence I think it's probably a proxy config error on my test container
[17:31] <stgraber> apw: are you the best contact for the ubuntu-fan autopkgtest?
[17:31] <stgraber> apw: trying to figure out what's going on with it on some arches... like here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/ppc64el/u/ubuntu-fan/20180824_171705_dff12@/log.gz
[17:32] <kyrofa> slangasek, can you apt install snapcraft?
[17:32] <stgraber> apw: I have no idea what that sd_bus_open_system is or where it's coming from, it's showing "FAIL" despite showing PASS two lines above so kinda confusing :)
[17:32] <kyrofa> If so, create a new directory, then run `snapcraft init`, then make snap/snapcraft.yaml look like this: https://paste.ubuntu.com/p/zSdZm3hFRS/
[17:32] <slangasek> kyrofa: ok sorted my proxy deal, adding it to /etc/environment was sufficient
[17:32] <kyrofa> Ah, okay
[17:32] <slangasek> apt installing now
[17:33] <kyrofa> slangasek, if you can  hit the store, just `sudo snap install hello` and run `hello.universe`
[17:33] <kyrofa> No need to use snapcraft
[17:47] <slangasek> ok so I've tried all the settings from launchpad (with the exception of mount.auto and network which don't appear relevant) and I still get the apparmor errors from cosmic snapd in the container
[18:00] <xnox> stgraber, i believe apw is out for a few weeks =/ i guess try bjf or some such?
[18:03] <stgraber> smb: I think you touched ubuntu-fan not too long ago too ^
[18:03] <stgraber> anyway, I guess I'll setup a test system to see what's up with that, hopefully it's something pretty simple and we can unstick LXD
[19:20] <xnox> stgraber, the patches touch Makefile.am & configure.ac, and they were generated with automake-1.15 yet cosmic now has automake-1.16 thus autopkgtests now fail.
[19:21] <xnox> stgraber, i wonder if automake needs to be added to build-deps explicitely somehow and/or autoregen needs to be run by the autopkgtest or something
[19:21] <xnox> e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/i386/l/lxc/20180824_181711_74458@/log.gz
[19:21] <xnox> somehow src/config/missing tries to run aclocal-1.15 which is no longer available
[19:22] <stgraber> xnox: oh, great, we finally have autopkgtest results for that one :)
[19:22] <tsimonq2> Odd_Bloke: Bumped you another year, but the DMB should really set that to autorenew. ;)
[19:22] <xnox> stgraber, hahahahhahaha
[19:22] <xnox> stgraber, yes, the KDE DDoS is almost over
[19:22] <stgraber> xnox: I think "autoreconf -f -i" should take care of that, what do you think?
[19:22] <xnox> i wonder if that should just run a single pass with all-proposed=1 rather than all the cross-combinations of all the things.
[19:22] <xnox> stgraber, yes, and i thought debian/rules do that already anyway....
[19:23] <stgraber> xnox: debian/rules does, debian/tests/exercise doesn't
[19:23] <xnox> stgraber, not sure if this is specific to debian/tests/exercise code path
[19:23] <xnox> stgraber, right
[19:23] <stgraber> kinda surprise that didn't hit us before
[19:23] <Odd_Bloke> tsimonq2: Thanks!
[19:23] <xnox> stgraber, i think automake-1.16 has only migrated half-way throught the autopkgtest doom
[19:24] <xnox> and it was automake 1.15 since like pre-xenial
[19:26] <stgraber> xnox: uploaded the autoreconf fix, hopefully that'll work
[19:27] <xnox> thanks
[19:27] <stgraber> and will take less than a day before I get a result :)
[19:27] <xnox> stgraber, we shall find out on tuesday
[19:27] <xnox> =)))) holidays here
[19:28] <stgraber> I'm traveling for the next two weeks but should still have time to deal with getting all my stuff to move to the release pocket and prepare the SRUs
[19:45] <tsimonq2> Odd_Bloke: No problem; I went ahead and fixed ACls.
[19:45] <tsimonq2> *ACLs
[19:47] <tsimonq2> infinity: Speaking of ACLs and such, since I just sent the email for the Ubuntu Membership Board, how's the TB stuff coming? All I remember is that you kept asking wxl to keep applying another round of Democracy™.
[19:48] <tsimonq2> infinity: Perhaps it just needs sabdfl to get the ball rolling?
[19:56] <infinity> tsimonq2: That exactly.  It's in his hands, and *shrug*
[21:54] <stgraber> xnox: looks like that worked
[21:54] <stgraber> xnox: green on s390x now
[22:08] <xnox> stgraber, whoop whoop