[00:02] <Logan> nacc: curious why you added a php-mbstring build dependency for php-finder-facade, since it doesn't seem like it needs it
[00:09] <slangasek> Unit193: thanks for the pointer to bug #824943, but I'm not sure how you concluded I missed it, since that package had not been uploaded to the NEW queue at the time you wrote that :)
[01:03] <Unit193> slangasek: ESP!  But I saw ubuntu-core-launcher hit and looked at its changelog.  (And not sure/mistook that for snapd, partially because breaks and rest because tired.)
[03:55] <nacc> Logan: hrm, i'm assuming i saw testcase failures w/o it. I will reverify tmrw AM.
[03:56] <Logan> nacc: ok cool, thanks
[03:56] <Logan> nacc: also you're aware that phpunit doesn't install properly at the moment, right?
[03:57] <Logan> phpunit : Depends: phpunit-mock-object (>= 3.1) but 3.0.6-1+ubuntu1 is to be installed
[03:58] <nacc> Logan: wasn't, but will add it to the list :) -- merging and getting 16.10 sync'd to Debian is my goal for this week across the php landscape
[03:58] <nacc> Logan: i assume that was in 16.10 (and not 16.04)
[03:58] <Logan> yep, that's correct
[03:58] <Logan> I've been helping out with some syncs, at least :P
[03:58] <nacc> Logan: thanks for letting me know, will get it fixed
[03:59] <Logan> nacc: https://www.dropbox.com/s/j8upo5sbothxfi3/Screenshot%202016-05-22%2023.59.34.png?dl=0
[03:59] <Logan> cheers :)
[04:37] <slangasek> nacc: that's only in yakkety-proposed... I may have mentioned this earlier, possibly when you weren't looking at your IRC client :)
[04:39] <cpaelzer> good morning
[05:45] <pitti> Good morning
[05:45] <pitti> Odd_Bloke: there's the upstream and Debian bug, not aware of a separate Ubuntu bug
[05:46] <pitti> smoser: import tempfile> eww, ugly; that's also new since yakkety's py3?
[06:07] <pitti> stgraber: the lxc failure is something else (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/l/lxc/20160521_010203@/log.gz)
[06:07] <pitti> stgraber: we do have yakkety cloud images, but the test is looking for a yakkety-server-cloudimg-amd64-root.tar.xz which doesn't exist in https://cloud-images.ubuntu.com/yakkety/20160519.1/
[06:07] <pitti> stgraber: did that maybe get renamed to -lxd.tar.xz?
[06:48] <dholbach> @pilot in
[07:10] <seb128> enjoy dholbach ;-)
[07:56] <Saviq> pitti, morning, can you please re-run http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api with --all-proposed?
[07:56] <pitti> Saviq: will do, once the x86 backlog clears (we had some problems over the weekend)
[07:56] <Saviq> ack
[08:08] <Odd_Bloke> pitti: In yakkety, we're consolidating to just the squashfs; I believe stgraber and co. need to do some work before lxd will support that. :)
[08:09] <pitti> Odd_Bloke: I take it droping -root.tar.xz was on purpose? but it sounds like -lxd.tar.xz would mostly replace it for nwo
[08:09] <pitti> Odd_Bloke: stgraber force-badtest'ed lxc because of "missing yakkety images", but that just hides the real bug
[08:10] <Odd_Bloke> pitti: -lxd.tar.xz is just the lxd metadata.
[08:10] <pitti> oh
[08:10] <Odd_Bloke> pitti: Dropping the -root.tar.xz was intentional, yes. :)
[08:31] <pitti> Odd_Bloke: oh, and the -disk1 suffix got dropped as well? /me adjusts adt-buildvm-ubuntu-cloud
[08:38] <Saviq> Mirv, we seem to have a problem https://launchpad.net/ubuntu/+source/qtchooser/58-gfab25f1-1
[08:38] <Saviq> qtchooser : Breaks: libqt5core5a (< 5.5.1+dfsg-17~) but 5.5.1+dfsg-16ubuntu11
[08:43] <Mirv> Saviq: yes, I noticed it about 1h ago when my builds started breaking too. I uploaded https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-17ubuntu1
[08:43] <Saviq> Mirv, ack
[08:43] <Saviq> pstolowski, ↑
[08:44] <Mirv> it got autosynced from Debian where they did simultaneous uploads
[08:50] <zyga> ogra_: hey
[08:50] <zyga> ogra_: around?
[08:52] <pitti> sil2100: to confirm, we won't build any touch products from yakkety, right? we'll move to xenial
[08:53] <sil2100> pitti: hey! Yes
[08:53] <pitti> sil2100: hey, how are you?
[08:53] <pitti> sil2100: and long-term we'll move away from system-image towards snappy, right?
[08:54] <pitti> sil2100: in systemd we still have that awful patch to use /etc/writable/; it's our only delta, so I'd like to sync systemd in yakkety now, as we won't need that patch anytime soon (or not at all any more)
[08:54] <pitti> we can restore it at some point if needed, but I see no need dragging it along all that time
[08:58] <Odd_Bloke> pitti: Yep; we'll be sending out an email with the details (once we're sure they're fully implemented ^_^).
[08:58] <pitti> Odd_Bloke: I did http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=6676ed6 for now, this seems to work
[09:05] <sil2100> pitti: hm, so the end-plan is to use snappy, yes, but that's still a bit far from now
[09:05] <sil2100> Since I'm not familiar with those parts, what would be the impact of dropping the patch?
[09:05] <Odd_Bloke> pitti: FWIW, if you were consuming streams it should have Just Worked (TM). :)
[09:06] <pitti> sil2100: in a yakkety-based touch image you couldn't set the time zone through timedatectl, and hence through the settings app
[09:07] <pitti> Odd_Bloke: you mean parsing http://cloud-images.ubuntu.com/daily/streams/v1/com.ubuntu.cloud:daily:download.json ?
[09:08] <pitti> if that's a stable format, I can do that
[09:25] <seb128> pitti, imho if we start dropping "things touch needs" we should record them in a bug
[09:26] <pitti> seb128: I can do that, no problem
[09:27] <seb128> pitti, but yeah, same line of thinking than when we said that packagekit 1.0 is fine because click isn't going to be needed by touch in y any time soon
[09:27] <seb128> speaking of which
[09:28] <pitti> seb128: is there a bug for that? I'll look at that one then to use the same tags and similar title
[09:28] <seb128> doko, mvo, it might make sense to just drop aptdaemon-pkcompat in yakkety and use packagekit aptcc instead?
[09:29] <seb128> pitti, not yet no, I just though now when I saw your systemd question that we should probably record the "known brekages" somewhere
[09:30] <ogra_> zyga, just returned from dentist, whats  up
[09:30] <ogra_> ??
[09:31] <pitti> seb128: I filed bug 1584671 with a  dropped-ubuntu-touch-patch tag for now
[09:31] <seb128> pitti, thanks
[09:32] <zyga> ogra_: hey :-)
[09:32] <zyga> ogra_: I sent this via email now
[09:32] <zyga> ogra_: feel free to ping me here for details
[09:32] <pitti> seb128: actually, I renamed it slightly as it's a patch for system-image, not touch per-se
[09:33] <seb128> well, it impacts the touch flavor
[09:33] <seb128> but I'm not picking on the name
[09:34] <pitti> seb128: I mean I retitled the bug, I kept the tag
[09:34] <pitti> but feel free to adjust, I don't mind
[09:35] <seb128> oh, ok
[09:35] <seb128> no, looks good to me
[09:35] <seb128> pitti, thanks!
[10:02] <dholbach> @pilot out
[10:03]  * dholbach will do some more piloting tomorrow... too much going on today
[10:17] <jamespage> cjwatson, morning
[10:18] <jamespage> cjwatson, do PPA's ever forget about previous versions uploaded?  having some hassle around some packages in Debian that don't use consistent orig.tar.xz's (generated from git tags...)
[10:19] <cjwatson> jamespage: Never.
[10:19] <jamespage> cjwatson, I thought that was the answer - thanks for confirming...
[10:19] <cjwatson> jamespage: Then again the Debian archive only forgets about those semi-randomly and over a fairly long timeframe.
[10:19] <cjwatson> jamespage: So it's not like using inconsistent orig tarballs is free of problems there either.
[10:19] <jamespage> cjwatson, this is a bit of a pet peeve for me atm
[10:19] <cjwatson> I'm sure.
[10:20] <cjwatson> Not going to change in LP though :)
[10:20] <jamespage> cjwatson, I appreciate that - we'll figure out some sort of workflow to try limit this from happening
[10:20] <cjwatson> You can use a different PPA if absolutely necessary; they're only remembered within a single archive.
[10:20] <jamespage> I can fake-sync it for now
[10:20] <cjwatson> But same file name with different contents isn't a good look.
[10:21] <jamespage> cjwatson, for the packages we're directly maintaining for openstack in ubuntu this is not a problem, as we're using pristine-tar and a gbp based workflow atm across the team
[10:21] <jamespage> its more of a problem where we're participating in pkg-openstack in Debian, where the policy is not that...
[10:22] <jamespage> ho-hum
[11:11] <Odd_Bloke> pitti: Yep, that's streams; talk to smoser to check if there are already tools that will do what you want. :)
[11:11] <pitti> Odd_Bloke: in Ubuntu we have some python-simplestreams and simplestreams CLI, but they aren't available on Debian; so it's "parse the JSON" or continue the "guess URL" approach
[11:13] <Odd_Bloke> pitti: Ah, of course. :)
[11:20] <rbasak> pitti, smoser: simplestreams should be fairly trivial to get into Debian I think, if somebody wants to do that.
[11:21] <seb128> slangasek, pitti, xnox, hey ... so upstart in yakkety-proposed fails to build on s390x and that blocks unity to land (which blocks important fixes to be SRUed because Trevinho wanted to be good citizen and land to devel before SRU) ... since nobody seems to have slot to work on the upstart build, any objection if we delete that version from y-proposed to unblock unity?
[11:21] <seb128> Laney, Trevinho, ^
[11:22] <rbasak> pitti: the format is logically stable, but you should pass your parse logic by me or smoser since some parts of that are designed to change.
[11:23] <rbasak> (eg. don't assume that searching for a set of things by key will always result in one image if it does right now; use product IDs if you need a particular thing, etc)
[11:29] <Trevinho> pitti: hey!
[11:29] <Trevinho> pitti: also, could you re-review the upower patch? :)
[11:35] <seb128> Trevinho, let's wait a bit for them to reply and delete it by mid-afternoon to unblock unity if they don't?
[11:35] <Trevinho> seb128: ok
[11:39] <seb128> Trevinho, you can prepare the SRU meanwhile ;-)
[11:39] <Trevinho> seb128: sure, so... You'd say to keep things in one branch or, just I prepare a debsrc and you can upload... what you prefer? :)
[11:40] <seb128> Trevinho, you are going the work so as your prefer
[11:40] <seb128> if silo works fine just go with that
[11:40] <Trevinho> seb128: silo is fine for me, but... It takes longer in general, to get uploaded
[11:40] <seb128> why?
[11:40] <Trevinho> if someone can then upload that quickly, I'm fine with it
[11:41] <seb128> it just takes the time to get the build in the ppa done
[11:41] <Trevinho> seb128: people deosn't see it?
[11:41] <seb128> but then you spare it in proposed
[11:41] <seb128> oh, you mean in the queue?
[11:41] <Trevinho> seb128: see the other SRU branches I've:https://requests.ci-train.ubuntu.com/#/user/Trevinho
[11:41] <seb128> I don't think so
[11:41] <Trevinho> they're still waiting
[11:41] <Trevinho> I've pinged people in ubuntu-release, but still...
[11:41] <seb128> it's just SRU team being busy/not picking those
[11:42] <seb128> I don't think manual upload would solve that
[11:42] <seb128> though the fact that there is no diff handy in the queue webui might make a few reviewer skip over it
[11:42] <seb128> lunch, bbiab
[11:43] <Trevinho> seb128: mh, yeah... I see
[11:52] <Saviq> pitti, hey, can you please rerun http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api with --all-proposed again, a Qt issue (resolved since) prevented the previous runs from completing
[12:29] <pitti> rbasak: http://autopkgtest.ubuntu.com/packages/m/mysql-5.7/yakkety/ppc64el/ is very flaky, I'll add a hint for that now; but I suppose mysql on ppc64el is a supported thing, can your team look into that?
[12:31] <pitti> seb128: right, the queues fill up faster than they get processed, and hardly everyone gets back to t or w I figure :/
[12:32] <pitti> Saviq: that goes for e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#webbrowser-app as well I suppose
[12:32] <Saviq> pitti, looks like it, yes
[12:33] <pitti> Saviq: same issue as in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/u/ubuntu-system-settings-online-accounts/20160523_090119@/log.gz ?
[12:33] <Saviq> pitti, most likely yes
[12:34] <Saviq> pitti, and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtdeclarative-opensource-src could use an --all-proposed re-run,too
[12:34] <Saviq> and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
[12:34] <Saviq> ...
[12:34] <Saviq> omg we really want a new unity8 in the release pocket...
[12:35] <pitti> Saviq: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 -> not installable
[12:35] <Saviq> pitti, yeah, I know, working on it
[12:35] <pitti> ok
[12:35] <Saviq> it's blocked by http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api
[12:36] <Saviq> which is why I was asking for a re-run there
[12:37] <pitti> Saviq: queued
[12:37] <Saviq> thanks
[12:38] <rbasak> pitti: looks like it needs a deep dive. I'm not sure that's within our remit. jgrimm, please can you advise? MySQL dep8 is flaky on ppc64el only.
[14:06] <Saviq> pitti, I think we need to push http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api through - without it http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-shell doesn't build and so unity8 is uninstallable... and we're going in circles
[14:06] <pitti> Saviq: builds happen against -proposed, so I don't understand how that would help?
[14:07] <pitti> https://launchpadlibrarian.net/260775998/buildlog_ubuntu-yakkety-amd64.unity-scopes-shell_0.5.7+16.04.20160505-0ubuntu2_BUILDING.txt.gz FTBFS on some C++ errors
[14:07] <Saviq> pitti, oh you're right, I thought it was waiting for unity-scopes-api (it was on Friday) - now it just FTBFS, and we've a fix cooking there
[14:08] <seb128> grar
[14:08] <Saviq> pitti, ok, then we should be back in business soon
[14:09] <seb128> Trevinho, Laney, upstart from yakkety release is also missing a s390x build (unsure how that happened) so deleting the proposed version didn't help :-/
[14:09] <Trevinho> ouch
[14:09] <Trevinho> so, going for new silo?
[14:09] <pitti> seb128: I think xnox already removed the s390x binaries before, so that we stop blocking on s390x ftbfs
[14:10] <ricotz> seb128, ah, I guess the libreoffice xenial-i386 build would just need a retry
[14:11] <seb128> ricotz, hum, unsure who cancelled it/why ... thanks for pointing out, I just retried
[14:11] <ricotz> https://launchpad.net/ubuntu/+source/libreoffice/1:5.1.3-0ubuntu1/+build/9771317
[14:11] <ricotz> seb128, I mentioned in #launchpad last week
[14:11] <ricotz> the builder was stuck
[14:12] <seb128> pitti, that doesn't help; unity buil-dep on libupstart-dev which doesn't exist at all
[14:12] <seb128> so the build depwait
[14:12] <pitti> seb128: ah, so we need to remove the s390x binaries of unity as well? (I'm surprised that didn't already happen)
[14:13] <seb128> pitti, I guess so, but then we need to remove any unity rdepends binaries as well?
[14:13] <pitti> right
[14:14] <seb128> not sure I want to go this road
[14:18] <ricotz> Mirv, hi, please note the *versioned* breaks of qtchooser against libqtcore4
[14:19] <pitti> apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt seems unhappy
[14:19] <pitti> apw: about "trying: linux" -- supposedly we need to remove all those transitional packages now?
[14:23] <apw> pitti, looking
[14:26] <seb128> Trevinho, I would force land with the missing build if it's possible, ask on -ci-eng
[14:26] <seb128> it's going to be stucked in yakkety-proposed but that's fine
[14:26] <seb128> somebody is eventually going to resolve the upstart/s390x issue
[14:26] <pitti> most likely not
[14:27] <pitti> it was removed from s390x quite deliberately
[14:27] <seb128> hum
[14:27] <pitti> so I think removing unity7 on s390x is the right solution
[14:28] <Trevinho> I guess there's no objection to that at all
[14:28] <pitti> in yakkety-release, so that an FTBFS on s390x doesn't block any more
[14:29] <seb128> ok, let's do that
[14:29] <pitti> xnox, slangasek: hmm, so if I have a /usr/share/upstart/sessions/{bamfdaemon,hud}.override containing just "manual", shouldn't that prevent the corresponding *.conf from starting? they still auto-start
[14:30] <seb128> but in any case it means we can land to silo to proposed
[14:30] <seb128> unity s390x is not going to build
[14:30] <pitti> yes, that's independent
[14:30] <seb128> Trevinho, can you ask about that?
[14:31] <Trevinho> seb128: about force landing?
[14:31] <seb128> yes
[14:33] <pitti> seb128: want me to remove unity7 on s390x, or are you on it already?
[14:34] <pitti> i. e. the binaries from the "unity" source, right? (not unity8)
[14:34] <seb128> pitti, I'm doing it
[14:34] <pitti> ack
[14:35] <seb128> done
[14:38] <apw> pitti, ok, so i assume we removed the lts kernels from yakkety sometime recently
[14:38] <pitti> apw: they have never been in x or y; I thought these binaries came from linux-meta and were just for upgrades from e. g. 14.04.3
[14:38]  * apw wonders if that makes any sense, no it doesn't
[14:39] <pitti> apw: but linux-meta in y should drop all these -wily etc. transitionals
[14:39] <pitti> maybe it did, and they became NBS and uninstallable now?
[14:39] <apw> pitti, right they should be being removed, but as yet we're still cpopying forward
[14:40] <pitti> apw: hm, but they should still be installable, they just depend on the "normal" image/tool in y
[14:40] <apw> pitti, but no they haven't been removed yet, because we're copying forward, and ^ that as you say
[14:40] <pitti> apw: oh, red herring
[14:40] <apw> so i don't think that can be what it is ocmplaining about
[14:40] <pitti> apw: linux-image-generic itself is also uninstallable
[14:42] <apw> pitti, is it?  isn't that just britney working out that linux needs linux-meta too ?
[14:42] <apw> pitti, doesn't the second and third (?) sets just saying we need a debian-installer for this to migrate ?
[14:42] <pitti> apw: that could be it; I tried in a schroot and it is installable
[14:43] <apw> pitti, the first attempet looks like linux alone, which never works
[14:43] <apw> i'll go check d-i
[14:43] <pitti> so let's blame the missing d-i rebuild
[14:43] <apw> and make one
[14:55] <Mirv> ricotz: right, good point, so it should be -7 or higher
[14:55] <ricotz> Mirv, I have commented on the bug
[14:55] <Mirv> ricotz: thanks!
[14:56] <ricotz> this breaks the world ;)
[15:05] <slangasek> seb128: sure; so while we're at it, why was upstart built again on s390x, I'm pretty sure I removed stale binaries once already this cycle...
[15:06] <slangasek> pitti: yes, my understanding is 'manual' should prevent an autostart :/
[15:06] <seb128> slangasek, if it shouldn't build it should probably be removed from the arch list? otherwise it looks like it was an error and people try to fix it?
[15:17] <Mirv> ricotz: 4.8.7+dfsg-7ubuntu1 uploaded now, but I can't follow up to see how it goes before tomorrow
[15:26] <ricotz> Mirv, thanks
[15:55] <pitti> slangasek: ok, thanks; the manpage seems pretty clear about it, but it doesn't actually prevent the job from starting
[15:56] <Saviq> pitti, ok, unity8 should be installable again according to rmadison, could you queue the unity8 run with --all-proposed again (although apt in a container here still doesn't see the required unity-plugin-scopes package)
[16:02] <pitti> Saviq: done
[16:08] <stgraber> pitti: yeah, CPC did that weird thing where they removed the images we said we may be able to remove this cycle before doing the needed work for us to be able to use the new format...
[16:09] <stgraber> pitti: so we're effectively stuck without working devel images and with failing lxc tests again...
[16:11] <stgraber> pitti: FYI https://bugs.launchpad.net/cloud-images/+bug/1577922
[16:17] <Odd_Bloke> stgraber: I'm pretty sure we all agreed to removing the images, and _also_ all agreed that we would remove them and people would fix things on their side.
[16:20] <stgraber> Odd_Bloke: I know I agreed with the former, the latter, I was under the impression would be done after it would actually be possible for folks to migrate to the new format, which it's not until you do the stream change we need
[16:21] <stgraber> Odd_Bloke: anyway, hopefully the change can go live soon and then I can start actually landing the needed change and then do another round of SRUs since this change missed the window for 2.0.1 (released last week). So it'll be another couple of months before people can use yakkety on xenial which is why I'm not super happy about it.
[16:22] <stgraber> Odd_Bloke: the initial ETA for the change (early May) would have worked, it getting moved to June screwed things up by making it miss our .1 bugfix releases, making it a .2 thing and so delaying the fix by a month and a half or so for our stable users
[16:25] <Odd_Bloke> stgraber: Understood, and that sucks; the changes required to the build system ended up being more complex than we were expecting.
[16:26] <Odd_Bloke> combined_sha256 should now be being produced for yakkety, but I see that it isn't currently; we'll dig into that and get that fixed.
[18:08] <hallyn> sladen: hey, https://wiki.ubuntu.com/apt-sync was filed in 2006, just curious, whatever happened with that?
[18:08] <hallyn> it sounds sweet :)
[18:08] <hallyn> would love for my apt-cache server to use that in the background
[19:04] <pitti> stgraber: thanks for the pointer
[19:05] <pitti> stgraber: could the tests use the images.linuxcontainers.org images for the time being? or would that be too much work?
[19:05] <pitti> stgraber: this is mostly just FYI; I just don't like having a force-badtest for lxc for an extended period of time, as it's very useful to detect regressions from new kernels and such
[19:05] <stgraber> pitti: the test already uses images.linuxcontainers.org for a bunch of images, the particular failing test is very specifically testing the ubuntu-cloud template
[19:06] <pitti> stgraber: oh, right
[19:06] <pitti> stgraber: so maybe an appropriate step for now would be to disable that test in yakkety?
[19:07] <rbasak> !dmb-ping
[19:07] <rbasak> We need one more for quorum.
[20:23] <elbrus> what does it take to end up on http://people.canonical.com/~ubuntu-archive/pending-sru.html
[20:23]  * elbrus expected cacti and cacti-spine there
[20:23] <pitti> elbrus: it's still in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1, i. e. hasn't been reviewed by the SRU team yet
[20:24] <elbrus> pitti: ok
[20:27] <elbrus> pitti: but what does "pending SRU" mean than?
[20:28] <pitti> elbrus: SRUs which got reviewed/accepted by the SRU team and are actually in *-proposed, and being tested
[20:28] <elbrus> ah, ok
[20:28] <pitti> once they get verified and moved to *-updates, they disappear from the page again
[20:31] <elbrus> pitti: at least you verified by your URL that the packages are on the SRU radar, which is really what I was interested in
[20:32] <pitti> right
[21:08] <juliank> What's up with the sbuild and apport regressions in xenial with apt 1.2.12? e.g. 'E: Unable to find a source package for procenv' for sbuild
[21:09] <juliank> hmm, does not seem to be apt related
[21:39] <Saviq> slangasek, infinity, I believe you guys have access to snakefruit, would you please queue a --all-proposed britney run of unity8 https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests thanks
[21:39] <mwhudson> tianon: hi, did you talk to anyone about containerd / runc yet?
[21:44] <slangasek> Saviq: looking at the excuses, it doesn't appear that will unblock anything given that unity8-common has an unsatisfiable depends on amd64
[21:44] <slangasek> (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8)
[21:45] <Saviq> slangasek, that's solved by now
[21:46] <slangasek> Saviq: oh, sorry, refreshing
[21:46] <Saviq> slangasek, I've just checked in a container here and I can `apt install unity8` with yakkety-proposed fine
[21:47] <slangasek> Saviq: right; I'm trying a more narrow trigger first, but will watch for results and retry with --all-proposed if necessary
[21:47] <Saviq> slangasek, I can tell you a normal trigger will fail
[21:48] <Saviq> slangasek, because we've a unity-api released that's too new for the released unity8 (yes, we need to think about our Depends there)
[21:48] <slangasek> Saviq: my "normal" trigger has about a half dozen --trigger options passed to it in order to test the packages all at once
[21:49] <Saviq> acl
[21:49] <Saviq> ack, even
[21:49] <slangasek> I may have missed some, in which case yes I'll give up and use --all-proposed ;)
[22:03] <clivejo> can anyone help me with a "stack smashing detected" crash and how to find out if its being caused by AppArmor?
[22:03] <jtaylor> clivejo: its a compiler added check
[22:03] <jtaylor> it usually means a buffer overflow
[22:03] <jtaylor> or probably always
[22:04] <jtaylor> clivejo: run with valgrind it is likely to tell you where
[22:04] <clivejo> so its not AppArmor causing it?
[22:04] <jtaylor> no
[22:04] <sarnold> clivejo: it'd be a very strange program if an AppArmor denial caused this
[22:04] <sarnold> it'd still be a bug in the program of course :)
[22:36] <clivejo> how do I get a decent bt with these new ddeb files?