[00:05] <cjwatson> xnox: maybe -std=gnu99?
[00:05] <cjwatson> xnox: i.e. C99 with GNU extensions
[00:05] <cjwatson> xnox: that seems less likely to have undesirable side-effects here
[00:11] <cjwatson> slangasek: sounds like https://bugs.launchpad.net/bugs/1524980 is for you
[00:17] <xnox> cjwatson, so -stc=c99 was explicitely introduced when porting to new lttng, and at the time we were still on gcc4 and thus on pre-99 standards by default. imho a future self would prefer to not hard-code standards versions, as the default one is now sufficient.
[00:17] <xnox> (and maybe doko will be less grumpy in the future "drop c99 transition")
[00:18] <cjwatson> xnox: perhaps.
[00:19] <cjwatson> xnox: remember dual-landings for vivid though.
[00:19] <cjwatson> xnox: I think -std=gnu99 might be more practically helpful for that
[00:20] <xnox> right, yes.
[00:20] <cjwatson> or -std=gnu11 if that works for vivid
[00:20] <cjwatson> probably not safe there though
[00:20] <xnox> no no no no no
[00:20] <cjwatson> yeah, ABI fun
[00:54] <psusi> cjwatson, I've finally gotten around to putting together an application for core-devel, think you can endorse?  https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication2
[01:16] <slangasek> cjwatson: :/  whatever happened to the idea of driving SRUs with p-m?
[05:13] <pitti> Good morning
[05:13] <Unit193> Howdy.
[05:21] <pitti> robru: I got tons of autopkgtest worker failures because you try to run xenial tests against the overlay PPA, but that does not have xenial indexes
[05:21] <pitti> robru: so that won't work for you -- can you please only use the overlay for stable releases where it publishes stuff?
[05:21] <pitti> robru: it seems PPAs don't publish empty indexes in that case
[05:23] <cody-somerville> mhall119 (or anyone else with necessary permissions): Hi there. My membership expired in ubuntumembers. I would have renewed my membership but I was having problems with SSO (RT #54895). Would you be able to re-enable my membership please? :)
[05:23] <robru> pitti: hmmm, you can't just make it handle missing index files?
[05:24] <pitti> robru: no, I don't want to silently hide apt errors
[05:24] <pitti> robru: you'd get wrong test results for typos, or if the PPA does not have what you expect, etc.
[05:27] <pitti> robru: I'll improve the error mode that it doesn't serial-kill workers (because they think that's a temporary failure and try again) but instead give you an error log
[05:29] <robru> pitti: OK I'll have to think of a way to improve the template
[05:29] <pitti> robru: that, or you actually upload something to the overlay PPA for xenial
[05:29] <robru> pitti: Hmmmmmmm
[05:30] <robru> pitti: can you check my emails? There's a weird traceback coming from vivid
[05:30] <pitti> robru: I will, just need to put some fires out first
[05:31] <robru> OK
[05:31] <robru> pitti: let me know if the staging Britney is causing issues, it will trigger every 15 minutes, i can turn it off if you want
[05:32] <pitti> robru: http://autopkgtest.ubuntu.com/running.shtml has some queued tests for xenial including the xenial overlay PPA; I'll need to delete them
[05:32] <pitti> robru: and if it sends ongoing requests, they will keep being stuck in a loop
[05:33] <pitti> robru: honestly, I think uploading a dummy package to the xenial overlay PPA is the nicest solution
[05:33] <pitti> robru: I guess eventually it'll get real packages anyway, and thus you don't need to care about special cases
[05:33] <robru> pitti: "eventually" i feel is years away ;-)
[05:33] <pitti> robru: how about hello 2.10-1~xenial1
[05:34] <robru> But yeah i would prefer the code not have special cases
[05:34] <pitti> robru: uh? I had expected from roughly March
[05:34] <robru> pitti: sure
[05:34] <robru> pitti: i thought phone will be vivid forever and ever...
[05:34] <pitti> then these test requests can even stay in the queue
[05:35] <pitti> robru: no, it can't -- no security support for vivid from January on
[05:35] <robru> pitti: i understood we had an exception for that.
[05:36] <robru> pitti: anyway, no matter now. Thanks for copying that package in.
[05:37] <pitti> robru: ok, so let's do that then? I'll backport hello and put it there, so that it's actually older than xenial and it's not going to get in the way?
[05:40] <stgraber> pitti: the way we dealt with such things in the past (extras.ubuntu.com) was to binary-copy a package from series-1 to the new series, wait for the publisher to run, then remove it
[05:40] <stgraber> pitti: that way nothing ever actually builds, you get your new index files and nothing is actually in the repo after it's cleaned up
[05:40] <pitti> stgraber: oh, PPAs won't clean up the indexes after the series became emtpy?
[05:40] <stgraber> pitti: nope, they won't
[05:40] <pitti> ah, good
[05:40] <pitti> I uploaded hello now
[05:41] <pitti> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.status_filter=published&field.series_filter=xenial
[05:44] <stgraber> hmm, what's odd is that xenial seems to have been created a few months ago according to timestamps in http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu/dists/xenial/
[05:44] <pitti> stgraber: well, I checked 10 mins ago and it wasn't there
[05:45] <pitti> maybe it used to have a package, and it was then removed?
[05:45] <pitti> as the new hello isn't even published yet
[05:45] <robru> pitti: oh i was thinking it would be fine with the same version, just binary copy in. Hello isn't seeded so it wouldn't make a difference
[05:45] <stgraber> well, even if that was the case, the structure seems valid, so not sure why apt would fail on it
[05:46] <pitti> robru: yeah, true that; but *shrug*, doesn't matter much really
[05:46] <pitti> stgraber: well, it will now
[05:46] <pitti> stgraber: but as I said -- these weren't there 10 mins ago
[05:47] <pitti> oh, wait!
[05:47] <stgraber> weird, I don't get how fresh files can have timestamps going back a couple of months, unless the publisher is doing something very weird :)
[05:47] <pitti> http://ppa.launchpad.net/ci-train-staging-area/stable-phone-overlay/ubuntu/dists/xenial/main/source/
[05:47] <pitti> that was the URL it complained about
[05:47] <pitti> it's staging-area, not service, sorry
[05:47] <pitti> robru: so we just need to do that trick for the staging PPA
[05:48] <stgraber> ah, that makes a lot more sense :)
[05:48] <robru> Yeah
[05:48] <pitti> and I'll delete hello again from the prod one
[05:51] <pitti> Signer has no upload rights to this PPA.
[05:51] <pitti> meh
[05:52] <pitti> robru: ^ seems you need to do that for the staging PPA yourself?
[05:52] <pitti> copy-package -s xenial --to=ppa:ci-train-staging-area/ubuntu/stable-phone-overlay -b hello
[05:52] <pitti> is what I tried
[05:52] <robru> Ooh hah, sorry.
[05:52] <robru> One sec
[05:57] <robru> pitti: ok, just did the copy, let me know if/when autopkgtest stops exploding
[06:14] <pitti> robru: ah, at last -- http://ppa.launchpad.net/ci-train-staging-area/stable-phone-overlay/ubuntu/dists/xenial/ exists now
[06:17] <pitti> infinity: thanks for subversion and git on s390!
[06:47] <sam_yan> hi
[06:51] <pitti> $ run-autopkgtest -s xenial -a s390x --trigger libpng/1.2.54-1 libpng  → http://autopkgtest.ubuntu.com/packages/libp/libpng/xenial/s390x/
[06:51] <pitti> slangasek, xnox ^
[06:52] <sam_yan> exit
[06:54] <slangasek> pitti: \o/
[06:55] <pitti> slangasek: next steps: configure enough workers, requests tests for all packages that are already built and have tests to prime it, and enable in britney
[06:57] <sam_yan> d
[06:58] <sam_yan> hi. Does ubuntu overwright the cups
[07:00] <darkxst> sam_yan, I've not seen an ubuntu cup ;)
[07:00] <darkxst> hey pitti
[07:01] <sam_yan> are you sure ?
[07:01] <sladen> darkxst: http://localhost:631/ on Ubuntu
[07:02] <darkxst> should I have included /sarcasm/ tags
[07:02] <darkxst> most likely there are ubuntu specific patches on cups
[07:02] <sladen> darkxst: I just assumed it naturally...
[07:20] <dholbach> good morning
[07:32] <Mirv> pitti: do you know why https://code.launchpad.net/~xnox/click/lp1522608/+merge/279522 hasn't been published to archives yet to unblock the UITK?
[07:34] <pitti> Mirv: no, I don't -- I suppose someone merged it into trunk, but didn't upload it?
[07:34] <Mirv> pitti: oh, it seems they're landing to both xenial and vivid overlay so it's now waiting for QA https://requests.ci-train.ubuntu.com/#/ticket/772
[07:37] <Mirv> hmm, technically cjwatson updated it being "ready for QA" which in train terminology would mean that the xenial part is ready for publishing (if necessary). however, we already missed the morning's image build opportunity so it probably doesn't hurt to wait until QA is up in roughly two hours.
[07:38] <Unit193> pitti: Any update on the dbus/systemd/policykit problem?
[07:59] <pitti> Unit193: "the" problem?
[08:00] <Unit193> Pinged you a couple weeks ago about a major problem when dbus is restarted (yes, not stuff crashing.  One requiring a hard poweroff.)
[08:00] <pitti> slangasek: FYI, http://autopkgtest.ubuntu.com/packages/a/ is now completely tested; I'm spoonfeeding some more batches
[08:01] <pitti> (b to k now)
[08:03] <pitti> Unit193: uh sorry, I don't remember; is there a bug report for this? (always better to keep stuff in a bug than on IRC)
[08:04] <Unit193> pitti: Yeah, was going to but don't know which one would be the best one to file it for.
[09:19]  * popey wonders why he's getting this on apt recently... "W: No sandbox user '_apt' on the system, can not drop privileges"
[09:19] <popey> (on xenial)
[09:22] <pitti> popey: that's new from apt 1.1; unfortunately it creates a new system user now and complains loudly if it's not there
[09:22] <popey> ah
[09:22] <popey> thanks
[09:22] <pitti> popey: I mostly see it in schroots, as that copies the host's passwd
[09:23] <pitti> popey: is that happening on your host system? because apt should have created that user on upgrade
[09:23] <pitti> $ getent passwd _apt
[09:23] <pitti> _apt:x:131:65534::/nonexistent:/bin/false
[09:23] <popey> on my laptop, yes _apt:x:134:65534::/nonexistent:/bin/false
[09:23] <darkxst> pitti, it just complains right? not breaks much?
[09:23] <pitti> no, just the warning
[09:23] <pitti> and you don't get teh privilege dropping
[09:23] <popey> hm, now it doesn't complain
[09:23] <popey> maybe I didn't update for a while
[09:24] <popey> sorry for the noise
[09:25] <darkxst> pitti, so long as it doesnt break all my schroots!
[09:28] <ginggs> hi, could the s390x build of petsc be removed please? it was caught up with the suitesparse/qt transition - i think it will be uninstallable now because the new suitesparse is now through to release
[09:32] <ginggs> LocutusOfBorg1: hi, are you planning to look at merging llvm-toolchain-3.7?
[09:35] <juliank> pitti: It's not unfortunate, it's security :)
[09:35]  * juliank also wanted to add seccomp sandboxing, but did not manage to do so (yet)
[09:36] <juliank> I have some plans that might allow us to get rid of _apt for 1.2 or later, though
[09:53] <pitti> juliank: oh, the "unfortunate" part that I meant was "relies on dynamic system user instead of using a static one"
[09:53] <pitti> juliank: dropping privs is doubleplusgood for sure!
[09:56] <juliank> pitti: Well, an existing static user would not be as safe, there are already other packages using them. That said, you can configure that, for example setting APT::Sandbox::User "daemon" in an apt.conf snippet
[09:58] <juliank> systemd also uses dynamic users, though, and surprisingly nobody complained about that
[10:20] <xnox> Mirv, pitti - re:click i believe cjwatson was landing it early hours this morning (e.g. merged things and prepared a silo)
[10:21] <xnox> pitti, you rock!
[10:43] <Mirv> xnox: yes, prepared a silo but it's not yet published
[10:44] <Mirv> xnox: however as it'd dual landing and it's in QA queue, I asked QA to prioritize it
[10:50] <Mirv> it seems it's under testing now
[11:45] <rbasak> Getting reports of grub2-signed being removed because it was not SRU'd in sync with grub2.
[11:46] <rbasak> Looks like there was a four hour window but fixed now.
[11:46] <rbasak> s/Getting reports/Got two reports/
[12:26] <__marco> Hello. Sorry to write here, but there is a bug report that I care that is stagnant. It would be a dream if it could be solved before the release of 16.04
[12:26] <__marco> https://bugs.launchpad.net/ubuntu/+source/vde2/+bug/776818
[13:05] <mhall119> cody-somerville: do you still need me to re-add you to Members?
[13:12] <rbasak> __marco: has any of the security issues raised been fixed upstream yet?
[13:12] <LocutusOfBorg1> ginggs, https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.7/+bug/1525122
[13:18] <ginggs> LocutusOfBorg1: ah nice! i'll sponsor that for you :)  does i386 build now?
[13:24] <LocutusOfBorg1> nope
[13:24] <LocutusOfBorg1> the problem about i686 I guess
[13:24] <LocutusOfBorg1> BTW FYI I drafted a MOTU application https://wiki.ubuntu.com/CostamagnaGianfranco/MOTUApplication
[13:25] <LocutusOfBorg1> you, pitti laney, seb128 dholbach have been my sponsor since almost two years now :)
[13:26] <seb128> LocutusOfBorg1, I can add something to the page for you
[13:26] <dholbach> LocutusOfBorg1: will look into it :)
[13:26] <dholbach> ... with pleasure
[13:26] <LocutusOfBorg1> thanks! :)
[13:26] <LocutusOfBorg1> actually I applied for DD just because it was easier to become an Ubuntu developer :)
[13:27] <LocutusOfBorg1> seb128, for i686 I plan to have a look as soon as I fix virtualbox and something else
[13:27] <seb128> k
[13:28] <LocutusOfBorg1> oops s/seb128/ginggs
[13:28] <seb128> I was wondering
[13:28] <seb128> btw seems like keyutils built!
[13:28] <LocutusOfBorg1> yes, and arrayfire built correctly almost everywhere, except for i386, where a similar issue is found
[13:29] <LocutusOfBorg1> I have the same issue on both packages lol :)
[13:29]  * LocutusOfBorg1 is wondering if there is a quick way to change the wiki page from https://wiki.ubuntu.com/CostamagnaGianfranco/MOTUApplication to https://wiki.ubuntu.com/GianfrancoCostamagna/MOTUApplication
[13:29] <ginggs> LocutusOfBorg1: i686, great.  will gladly endorse your motu application
[13:30] <LocutusOfBorg1> well, if possible please use this one https://wiki.ubuntu.com/GianfrancoCostamagna/MOTUApplication#preview
[13:34] <seb128> k
[13:35] <__marco> rbasak: please, read the comment #22. It is not necessary to include the whole vde to support it, a relative little library is enougth
[13:36] <__marco> I am waiting for any objection to fix it
[13:48] <cyphermox> good morning!
[13:49] <mdeslaur> hi cyphermox
[13:50] <cyphermox> hey mdeslaur
[13:50] <cyphermox> I've just been merging your usb-creator code and I gave it a quick run ;)
[13:50] <mdeslaur> cyphermox: ah, cool
[13:52] <cyphermox> I'll upload 0.3.0 in a few minutes I think
[14:15] <ximion> Laney: you should update your dep11-generator instance at Ubuntu to the latest Git master - I just landed some patches which have a really high impact on the amount of processed components
[14:26] <pitti> LocutusOfBorg1: oh, my pleasure! will write a blurb
[14:44] <pitti> didrocks: FYI, https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=30800f87
[14:44] <pitti> didrocks: I'll do a full integration test on production and document it, but this should now have everything you need?
[14:56] <tedg> xnox: Did you merge mterry's ftbfs branch into your branch?
[14:56] <tedg> xnox: Seems like Jenkins thinks it's not there.
[14:57] <tedg> xnox: Thanks BTW, it was on my TODO to figure out what was up with lttng this morning.
[14:57] <xnox> tedg, i set the branch as pre-requisite....
[14:58] <xnox> both of these things are in the ubuntu archive already, as they are blocking to have ubuntu-desktop & ubuntu-touch installable... please sort out branches/jenkinsii/landings.
[14:58] <xnox> and e.g. have been contributing to the large delay in landing the lot of migrations which transitively entangled a lot of things.
[15:02] <tedg> xnox: You need to merge it as well I think, I don't know that Jenkins pre-lands dependencies. Only helps in the diff view.
[15:02] <tedg> xnox: Cool, if that's the case I'll delay some on the silo and get some other MRs in there.
[15:02] <didrocks> pitti: looks good to me, I guess that will work with test-git="depot_url.git branch" from my tests, but I'll keep you posted :)
[15:03] <pitti> 'myproj {"test-git": "git://anonscm.debian.org/collab-maint/python-dbusmock.git"}'
[15:03] <pitti> didrocks: ^ that's what I'm currently running
[15:03] <didrocks> pitti: yeah, that checkout master though, sometimes I'm checking some branch
[15:04] <didrocks> but I'll give it a try with this
[15:04] <didrocks> out*
[15:04] <xnox> tedg, ok merged. and pushed. if it still doesn't work, then i don't know....
[15:05] <pitti> didrocks: ah, good point; yes, that needs another argument indeed, I'll extend it accordingly
[15:05] <didrocks> pitti: thx!
[15:05] <pitti> didrocks: perhaps "git://anonscm.debian.org/collab-maint/python-dbusmock.git mybranchname" ?
[15:06] <pitti> didrocks: meh, doesn't quite work yet, git clone is hanging on firewall issues; /me sees how to squeeze the proxy in there
[15:06] <didrocks> pitti: yeah, that's what I mean, I think that works
[15:06] <pitti> didrocks: so that will be split() and if there's a second argument it will become the --branch argument
[15:12] <buxy> hi,
[15:12] <buxy> any idea who handles Merge-o-matic?
[15:12] <buxy> The mom@ubuntu.com email address bounces with   mail_mom@casey.canonical.com
[15:12] <buxy>     Unrouteable address
[15:13] <didrocks> pitti: yeah, and then, I'll add to me wrapper the github particular support (splitting from url, so that I can lazely copy/paste)
[15:13] <buxy> cjwatson: ^ do you know?
[15:39] <pitti> didrocks: blergh, the proxy also doesn't allow access to anonscm.debian.org  .. which branch do you need in particular?
[15:40] <didrocks> pitti: something like git@github.com:ubuntu/ubuntu-make.git
[15:40] <didrocks> or the https equivalent:
[15:40] <didrocks> https://github.com/ubuntu/ubuntu-make.git
[15:41] <pitti> Received HTTP code 403 from proxy after CONNECT
[15:42] <didrocks> argh…
[15:42] <pitti> that smells like an RT now, not sure what else I can do :(
[15:42] <pitti> didrocks: perhaps you can set up an automatic Launchpad mirror?
[15:43] <didrocks> pitti: going to be difficult for contributors' branch
[15:43] <didrocks> like everything != master
[15:43] <didrocks> or any PR
[15:43] <pitti> didrocks: aren't you running this in the data center too? do you use the proxy?
[15:43] <didrocks> (there is already a launchpad mirror, but it's taking long sometimes to sync, and I'm talking about master)
[15:44] <didrocks> pitti: yeah, I do use it, on s-jenkins
[15:44] <didrocks> and have access to it
[15:45] <pitti> didrocks: ok, perhaps squid.internal has different policies depending on who requests it
[15:46] <didrocks> pitti: yeah, that's kind of weird. I do have access to dockerhub as well, do you from there?
[15:46] <pitti> didrocks: so I suggest you put a clone on Launchpad for now for testing, and I'll file an RT for allowing github
[15:46] <pitti> didrocks: git clone URL?
[15:47] <didrocks> pitti: is there any git <-> git cloning in launchpad?
[15:47] <didrocks> I was only knowing about a git <-> bzr one
[15:47] <didrocks> like the one I set up moons ago: https://code.launchpad.net/~ubuntu-desktop/ubuntu-make/master
[15:47] <pitti> well, we could start with that too :)
[15:48] <didrocks> pitti: good for testing, indeed, (but not enough for switching though)
[15:49] <pitti> didrocks: right, but would unblock you from dep8-ifying the tests
[15:50] <didrocks> indeed
[15:50] <didrocks> pitti: but do you mind testing access to dockerhub?
[15:50] <pitti> didrocks: do you have a clone url?
[15:51] <didrocks> pitti: if you want to pull via docker, you can try: docker pull didrocks/docker-umake-manual
[15:51] <didrocks> (I think it's just using some https://hub.docker.com/…)
[15:52] <pitti> ah, that's not git?
[15:52]  * pitti doesn't have docker installed there
[15:52] <didrocks> pitti: no, it's not using git for pulling images
[15:52] <pitti> nope, same thing
[15:53] <didrocks> pitti: I'm afraid then that all access to 3rd parties for real large tests would be the same…
[15:53] <pitti> I'm a bit confused, this seems to work reasonably well from scalingstack
[15:53] <pitti> but apparenlty not from prodstack
[15:53] <didrocks> yeah, can be different fiwall rules?
[15:53] <didrocks> firewall*
[15:53] <pitti> perhaps I need to do the git clone on the testbed then, instead of the controller
[15:54] <didrocks> oh…
[15:54] <pitti> didrocks: it all goes via proxy either way, so I rather suspect different policies on the squid side
[15:54] <didrocks> yeah
[15:54] <pitti> )#*$J#(J#*F(
[15:54] <didrocks> so many not a problem from the testbed, which would be good :)
[15:54] <pitti> so much for a small Friday afternoon hack
[15:55] <didrocks> pitti: don't tell me, feeling the same with some plymouthingy
[15:56] <Mirv> ok xenial should be now fixed, UITK + url-dispatcher + ubuntu-app-launch just migrated to release pocket thanks to fixed click
[16:01] <pitti> didrocks: ok, http://autopkgtest.ubuntu.com/running.shtml#pkg-myproj is running against a branch on LP
[16:01] <pitti> didrocks: but it seems I need to build this five times as complicated with a different approach now
[16:01] <pitti> didrocks: so, should be good enough for developing your tests while that happens (or the RT gets done)
[16:05] <pitti> didrocks: ok, confirmed that it all works fine from scalingstack
[16:06] <pitti> didrocks: so, there's a solution which can be implemented quickly
[16:10] <didrocks> pitti: sweet!
[16:10] <didrocks> thanks pitti :)
[16:23] <mdeslaur> infinity: hi! how do you suggest I fix the phpunit/php-codecoverage circular dependencies/build dependencies causing the php-codecoverage package to ftbfs?
[16:24] <mdeslaur> infinity: I'm sure you have a better idea than any hack I'm about to try
[16:51] <lamont> sometime 2-3 weeks ago, my xenial desktop stopped having audio in hangouts...  any clues?
[17:14] <doko> LocutusOfBorg1, File "/«PKGBUILDDIR»/lldb/test/lldbtest.py", line 868, in getPlatform
[17:14] <doko>     platform = lldb.DBG.GetSelectedPlatform().GetTriple().split('-')[2]
[17:14] <doko> AttributeError: 'NoneType' object has no attribute 'split'
[17:14] <doko> Config=i686-gcc-5
[17:15] <doko> I doubt that dropping the i686 fix had the expected result
[17:31] <infinity> mdeslaur: We bootstrap it in the bootstrap repo.
[17:34] <mdeslaur> infinity: oh. could you do that? or someone else in foundations?
[17:34] <mdeslaur> infinity: pretty please?
[17:34] <infinity> mdeslaur: It'll get done.  I need to update some chroots first.
[17:34] <infinity> mdeslaur: Which I think I'll do this morning.
[17:34] <mdeslaur> infinity: awesome, thanks
[17:34] <mdeslaur> infinity: I think that's the first step in the massive php failures in -proposed
[17:47] <LocutusOfBorg1> doko, even not dropping didn't have the expected result
[18:00] <doko> LocutusOfBorg1, are you working on this?
[18:27] <LocutusOfBorg1> doko, not now, it isn't a regression and I have more serious bugs to look at
[18:28] <doko> LocutusOfBorg1, interesting understanding about a regression
[18:29] <LocutusOfBorg1> well, llvm 3.7 was never built on i386
[18:29] <LocutusOfBorg1> so my "not a regression" actually means, "it will migrate to release anyway"
[20:07] <Saviq> can someone please restart http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/armhf/ with unity8 trigger
[20:10] <Saviq> the failure there was actually caused by a packagekit install fail
[20:11] <Saviq> s/packagekit/policykit/
[20:12] <infinity> Saviq: Sure.
[20:13] <Saviq> thanks, I'll ping the guys responsible to have a look at why is this unreliable