[08:39] <tvoss_> good morning
[15:13] <cwayne> plars, hey, wondering how to get the adb device on ashes that's used for touch_custom?
[15:13] <plars> cwayne: should be in the output log, one sec
[15:14] <plars> cwayne: 01ce848e48dfa6a2
[15:14] <plars> cwayne: it's not *super* clear, but it's in the log at 01ce848e48dfa6a2 toward the top
[15:16] <xnox> i need touch/autopilot expertise. Can I run all phablet-test-run deb/click tests in one go, without reseting/rebooting device in any way?
[15:16] <xnox> (as in does phablet-test-run sanity checks the environment before executing tests, and/or puts it back into a known state at the end) ?
[15:28] <cwayne> plars, so it looks like the gallery-app and ui-toolkit autopilot tests are somehow refusing to load a custom theme, which is why so many failures in touch_custom
[15:29] <plars> cwayne: ok, is that something you can confirm locally? do you need me to rerun things?
[15:30] <cwayne> plars, i've just confirmed it locally


[01:35] <user|16545> hi
[12:08] <BluesKaj> Howdy folks
[13:59] <viewer|12> hello, i have installed kubuntu 19.04 using lvm for partitioning; the question is why the system shows the boot loader menu although kubunti is the only OS installed
[14:59] <R13ose> How do I create a second desktop?
 Fwd from Testnet-Launch: 🚀 Hello! Good News! … 🚀 We have opened Dex-Platfrom! … 🚀 To celebrate the Binance DEX, we have committed a total of 5000 Bitcoin & 20000 Ethereum to give away to our fans worldwide. … ✅ Participate https://testnet-platforms.com … ✅ Official group t.me/joinchat/LU4tOFKj3cdTtLo2F4vC8Q
 System Settings->Workspace->Virtual Desktops
 the rows setting determines the configuration in your desktop Pager (default on Task Bar)
[21:48] <keithzg> Well shucks; I finally got around to rebooting since similarly finally enabling and installing from the backports PPA on my 18.04 LTS install here at work, and everything's borked now
[21:49] <keithzg> No system tray, no search results in the launcher or KRunner, right-clicking on the desktop does nothing----and probablyk other things I haven't noticed yet.
[21:50] <keithzg> (Among the things I hadn't noticed *until* now, apparently Freenode kicked my Matrix user out of this channel, and damned if I can convince it to let me back in, hah)
 FYI - after I removed the /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf file, not only does Discover work fine, but gparted does as well (issue posted a couple of days ago here)
 profile issue?
 never run into that before...
 work machine may have sso or other auth, so maybe not possible, but would be my first check
[21:54]  * keithzg is honestly just going to try purging the backports PPA first :P
[21:56] <keithzg> Everything worked fine until installing the backports PPA, so. Not like I desperately need the latest KDE packages on this machine, really.
[21:59] <keithzg> Does plasma still log to a file somewhere? I can't seem to find one.
[22:01]  * keithzg is just gonna go with Plan A, ppa-purge
[22:07] <keithzg> Yep, that solved everything.
[22:25] <valorie> keithzg: ppa-purge is the reason I feel that using backports is safe -- you have an out if it doesn't work
[23:04] <keithzg> valorie: Yeah, quite fair, it's a nice get-out-of-jail-free card :)
[23:12] <valorie> I've tried a few PPAs where it saved my install, yeah
[23:21] <Katnip> snap and flatpak has helped too


[03:17]  * micahg wonders if infinity or ScottK are available to take care of the -proposed regression asomething mentioned above
[03:33] <infinity> micahg: Sure.  I'm going to re-upload it with -v, so it snags the previous -proposed bugs as well, otherwise it looks fine.
[03:34] <micahg> infinity: you want me to do that so you can accept?
[03:34] <infinity> micahg: I've already reviewed it, if my source matches his, I think I can let it slide and accept. :P
[03:34] <micahg> ok
[03:35] <micahg> infinity: well, it just looks bad on the changes list, that's all
[03:36] <infinity> micahg: Not really, since the -changes list has no idea who accepted. :P
[03:36] <infinity> Anyhow, already re-uploaded an identical version with a more complete .changes
[03:37] <micahg> oh, right, that's another bug..
[03:37] <micahg> no audit trail for accepts I mean
[03:37] <infinity> Yeah, it's been "in progress" for months.
[03:40]  * infinity wonders if sru-accept removes all the regression tags, or if I'll have to do that by hand.
[03:41] <infinity> Hrm, looks like it doesn't.
[03:41]  * infinity wonders if perhaps it should...
[03:42] <infinity> Though, that messed with multi-package bugs.
[03:42] <infinity> Tags being attached to the bug instead of the taks make this all really messy. :/


[12:45] <ggoodman> Ahh, every time my computer idles, I lose all history from this channel! I tried googling to see if there are hosted archives and came up short. Anywhere I can read previous conversations? I'm not sure what I might have missed re: the hotplug spinning behaviour we hit last week.
[12:50] <ggoodman> To bring this into context, it appears that we picked up a newer version of cloud-init during recent AMI bakes based on Canonical's public ubuntu 18.04 image. As we rolled out the version of our service based on such AMIs we saw a significant and sustained increase in CPU and disk usage. We were able to eliminate code-level changes as contributing
[12:50] <ggoodman> factors and happened to observe the `cloud-init` process spiking in CPU on affected hosts. Comparison of versions on affected and unaffected hosts identified that this tool had been updated.
[12:51] <ggoodman> We also so that whereas on older hosts, the `/var/log/cloud-init.log` file did not change after initial boot, on affected hosts, this file was being written to in continuous bursts.
[12:52] <ggoodman> Some Googling led us to the documentation about tweaking when networking config should be applied: https://cloudinit.readthedocs.io/en/latest/topics/events.html#apply-network-config-every-boot. We attempted this 'fix' on a quarantined host and observed that it did not resolve the issue.
[12:53] <ggoodman> We were also unable to figure out how to pull in an older, unaffected version of cloud-init using `apt` as the version in use on unaffected hosts didn't appear to be available any longer.
[12:55] <ggoodman> Our resolution was to tweak our AMI build tooling to pin to an older version of the base ubuntu AMI and then use `apt` to put a hold on `cloud-init`. As a result, we're unable to continue picking up upstream ubuntu base images until this issue is resolved.
[12:58] <ggoodman> To put a visual on the impact across one deployment: https://imgur.com/a/4RJEt8E. The period where we were spiking to 100% was because the incremental CPU and disk load we were observing caused a bit of a cascade failure and required all hands on deck. The drop in load and variance thereof corresponds with when we finally got a working AMI built
[12:58] <ggoodman> and shipped with `cloud-init` pinned to the earlier version.
[13:39] <ggoodman> falcojr, it seemed like the linked logs confirmed some form of bug to you. If so, can you help me understand what you saw and how we should proceed to getting this properly reported?
[13:41] <falcojr> ggoodman: I'll create the bug and link it here
[13:42] <falcojr> to your IRC question, we have https://irclogs.ubuntu.com/
[13:43] <falcojr> for a brief summary, we added a new "hotplug" feature that allows a network device to be added to the system and cloud-init will detect it and automatically update the metadata and bring it up
[13:44] <falcojr> the behavior is disabled by default, but for newly added devices, we still do a check to see if we should do anything
[13:45] <falcojr> and the number of virtual interfaces generated by the docker containers is causing those checks to pile up and consume CPU
[13:50] <ggoodman> Is there any bit of configuration that would allow us to disable even that behaviour? I think some of our platform folks were a bit worried about wiping out the udev rules as that would put is kind of outside the cloud-init 'happy path'. While I don't 100% agree with that risk-assessment, any other options would be very welcome! :D
[13:55] <falcojr> ggoodman: Nothing I can think of at the moment. That udev rule is new to the latest release, and the fix will likely involve not writing the rule until we're sure we want the hotplug functionality enabled, rather than always writing it as we currently do
[13:56] <ggoodman> Thanks falcojr. Makes sense.
[13:57] <ggoodman> Do you happen to know if there's a (simple) way of installing a version prior to the introduction of the hotplug functionality via `apt`?
[14:03] <falcojr> we don't have a simple way of getting back to 21.2, but 21.1 should still be in main.  "apt install cloud-init=21.1-19-gbad84ad4-0ubuntu2"
[14:08] <ggoodman> Thanks :D
[14:19] <falcojr> ggoodman: https://bugs.launchpad.net/cloud-init/+bug/1946003
[14:21] <ggoodman> ❤


[07:43] <ikonia> rikmills: hi there, what's up ?
[07:44] <acheronuk> ikonia: just grouping an additional nick to my account
[07:46] <ikonia> just seen
[07:47] <ikonia> sor=ry
[07:47] <ikonia> sorry
[07:47] <acheronuk> np :)


[01:45] <mup> PR snapd#12811 opened: tests: make sure there are not any snapd service listed after removing snapd <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/12811>
[06:36] <mup> PR snapd#12812 opened: release: 2.59.4 <Squash-merge> <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/12812>
[07:16] <mup> PR snapd#12773 closed: tests: update  golang.org/x/net in muinstaller <dependencies> <Created by dependabot[bot]> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12773>
[08:25] <mup> PR pc-gadget#91 opened: Revert "Copy shim in EFI/ubuntu/shimx64.efi" <Created by alfonsosanchezbeato> <https://github.com/snapcore/pc-gadget/pull/91>
[08:30] <mup> PR pc-gadget#90 closed: Copy grub to EFI/ubuntu/ folder in seed partition <Created by alfonsosanchezbeato> <Closed by alfonsosanchezbeato> <https://github.com/snapcore/pc-gadget/pull/90>
[09:57] <mup> PR snapd#12812 closed: release: 2.59.4 <Squash-merge> <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12812>
[10:12] <mup> PR snapd#12680 closed: go.mod: update golang.org/x/net <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12680>
[10:17] <mup> PR snapd#12813 opened: packaging: merge changelogs for 2.59.{3,4} back into master <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/12813>
[10:37] <mup> PR snapd#12814 opened: tests: revert failing tests for 2.59 <Run Nested -auto-> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/12814>
[11:22] <mup> PR snapd#12813 closed: packaging: merge changelogs for 2.59.{3,4} back into master <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12813>
[13:44] <mup> PR snapcraft#4137 opened: Issue template <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/4137>
[14:29] <mup> PR snapcraft#4137 closed: Issue template <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/4137>
[14:34] <mup> Issue snapcraft#4138 opened: Detect pyproject.yaml in the core20 python plugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/issues/4138>
[15:44] <mup> PR snapcraft#4139 opened: github: update issue sync action <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/4139>
[18:24] <mup> Issue snapcraft#4140 opened: Flaky spread tests <Created by lengau> <https://github.com/snapcore/snapcraft/issues/4140>
[19:49] <mup> PR snapcraft#4141 opened: spread: let the core18 base test run longer <Created by lengau> <https://github.com/snapcore/snapcraft/pull/4141>
[23:30] <mup> PR # closed: snapcraft#4076, snapcraft#4091, snapcraft#4121, snapcraft#4134, snapcraft#4139
[23:35] <mup> PR snapcraft#4131 closed: tools: update tox config to latest starbase <Created by lengau> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/4131>


[12:14] <smartboyhw_> ypwong, JackYu: Good evening
[12:33] <JackYu> smartboyhw, hi
[12:46] <ypwong> smartboyhw_, hi
[12:46] <ypwong> JackYu, should i come over?
[12:51] <JackYu> ypwong, yep, welcome:)
[13:23] <ypwong> smartboyhw_, hey
[13:26] <ypwong> there?
[13:26] <smartboyhw_> ypwong: Cherrs
[13:26] <smartboyhw_> *cheers (damn)
[13:26] <ypwong> smartboyhw_, will ubuntu studio have any sessions in uds-1305?
[13:26] <smartboyhw_> Do say:)
[13:27] <smartboyhw_> ypwong: That's a very interesting question.
[13:27] <smartboyhw_> We are not planning for it for team discussion purposes
[13:28] <smartboyhw_> We might do a session where users can suggest features though.
[13:28] <smartboyhw_> ypwong: Why is that you askes?
[13:28] <smartboyhw_> *asked
[13:28] <ypwong> smartboyhw_, we're thinking about the need for any sessions for ubuntukylin
[13:29] <smartboyhw_> ypwong: The prob is that for China users 1400 UTC is 2200 BST
[13:29] <ypwong> right
[13:29] <ypwong> though we participated last time
[13:29] <smartboyhw_> ypwong: But you guys have a big team, we are small.
[13:30] <smartboyhw_> And you have Canonical.
[13:30] <JackYu> :)
[13:30] <smartboyhw_> JackYu: I am corrext
[13:30] <smartboyhw_> *correct
[14:38] <ypwong> https://launchpad.net/sprints/ubuntukylin-saucy
[14:39] <smartboyhw> ypwong: :O
[14:40] <ypwong> >:)


[00:15] <Saviq> robru, the test was invalid - it was trying to rebuild qtmir, which is not what autopkgtests are for and caused us trouble now that britney runs per trigger and not all of proposed
[00:15] <robru> ah
[00:16] <Saviq> thanks, g'night!
[00:16] <robru> Saviq: night
[02:04] <michi> trainguards: I have a weird failure in a silo.
[02:04] <michi> ppc64el fails, but there is no build log: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/9419613
[02:04] <michi> Anyone around who can help?
[02:05] <robru> michi: no idea. I just hit retry in the hopes that it gives a log next time
[02:05] <michi> It’s also failed in silo 59, same story there.
[02:06] <robru> Well that's troubling
[02:06] <michi> It’s clearly an infrastructure thing. All the other arches built fine.
[02:07] <michi> Trying a rebuild...
[02:08] <robru> michi: right but if it was a one off, it'd seem more likely to work on a retry. If there's consistent failures then we may need to escalate to Colin
[02:08] <michi> Yeah
[02:08] <michi> robru: When does Colin normally come online?
[02:08] <michi> I don’t see him right now.
[02:09] <michi> Ah, no, he’s around...
[02:09] <robru> michi: UK time officially but he's known to keep irregular hours
[02:09] <michi> Well, that makes it around 1 am or so over there...
[02:10] <robru> michi: anyway the retries have logs showing live, just a question of if it'll keep them after
[02:10] <michi> I’ll keep an eye on them, thanks.
[02:13] <michi> robru: This is not looking good: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/9419741
[02:14] <michi> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059/+build/9419724
[02:14] <robru> michi: huh beats me. Maybe try wgrant
[02:15] <michi> wgrant: ^
[02:15] <michi> Can you help?
[02:16] <michi> cjwatson: In the unlikely case that you are still around, it looks like something is broken with the ppc64el builders for the train.
[02:28] <wgrant> robru, michi: Looking.
[02:28] <robru> Thanks
[03:55] <bzoltan> jibel: popey: I have fixed the 35 silo, so it is fully OK - https://requests.ci-train.ubuntu.com/#/ticket/1095 If you want it on OTA10 please put it on a quick line to QA and see if it is good for you.
[04:42] <slangasek> robru: why do the silo descriptions link to swift objects that aren't readable? (e.g. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-066, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1186/2016-03-30_07:49:08/xenial/qtmir/content.diff)
[04:43] <robru> slangasek: because the artifacts are deleted when the silo lands
[04:43] <slangasek> robru: that silo isn't landed; it's stuck in -proposed
[04:43] <slangasek> robru: relatedly: why is the qtmir from that silo reported to no longer have any autopkgtests?
[04:43] <robru> slangasek: the description says landed right there. Probably force merged
[04:44] <slangasek> ok so who's force merging and why?
[04:44] <slangasek> (why do we even still allow force merges?)
[04:45] <robru> slangasek: Saviq asked me to force merge that one because it was stuck because of the same issue with dpkg breaking the packages to not run autopkgtests
[04:45] <slangasek> This doesn't get to land.  Someone needs to take responsibility for the fact that the autopkgtests have gone missing from the source.  Saviq ? (the only one of the three landers currently online...) http://autopkgtest.ubuntu.com/packages/q/qtmir/xenial/amd64/
[04:46] <slangasek> robru: what "same issue"?
[04:46] <robru> slangasek: it passed qa and just needed a small follow-up silo to fix the packaging to get it through proposed
[04:46] <robru> slangasek: the dpkg ftbfs in the backport ppa was meant to fix this
[04:47] <slangasek> hmm
[04:47] <robru> slangasek: instead Saviq started a new silo with packaging fixes that restore the autopkgtests
[04:48] <slangasek> I am unclear how it's dpkg's fault that the source package has no debian/tests directory
[04:48] <robru> slangasek: basically the autopkgtests were broken by my dpkg-buildpackage work because apparently vivid and newer automatically add the Testsuite: field but the trusty version doesn't
[04:48] <slangasek> or why it's acceptable to force-merge things that need source fixes in order to get into xenial
[04:48] <slangasek> robru: I just downloaded the source package from the archive; it has Testsuite: in the .dsc file
[04:49] <slangasek> but there are no actual debian/tests in the source package
[04:49] <robru> slangasek: Hmmmmmmm
[04:49] <robru> slangasek: i didn't actually look at it, I'm just going off what pitti told me
[04:49] <slangasek> $ pull-lp-source qtmir && grep Testsuite qtmir*.dsc
[04:49] <slangasek> Testsuite: autopkgtest
[04:49] <slangasek> $
[04:50] <robru> slangasek: pull-lp-source? That'll grab what's in xenial, not the broken one stuck in proposed
[04:50] <slangasek> nope
[04:50] <slangasek> pull-lp-source pulls the latest, == -proposed
[04:53] <robru> slangasek: so I'm just going off https://bugs.launchpad.net/bileto/+bug/1564084
[04:53] <ubot5`> Launchpad bug 1564084 in Bileto "Does not automatically add "Testsuite:" header any more" [Undecided,New]
[04:54] <robru> slangasek: and this is the silo Saviq put together to fix it: https://requests.ci-train.ubuntu.com/#/ticket/1206
[04:55] <slangasek> robru: right, so that's unrelated to what has happened to qtmir
[04:55] <slangasek> that bug reports a problem with a unity8 package, not with qtmir.  qtmir has the Testsuite header, autopkgtest tries to test it, and it fails because there are no tests in the source (and I can't see from the diff where they've gone)
[04:56] <slangasek> robru: however, if this was the bug you had suggested "only affected unity8", then that should certainly not be the case
[04:56] <robru> slangasek: https://code.launchpad.net/~saviq/qtmir/drop-testsuite-header/+merge/290468
[04:57] <slangasek> robru: where did the *tests* go?
[04:57] <robru> slangasek: Saviq said somewhere they were no good so he got rid of them.
[04:57] <slangasek> hmm
[04:58] <robru> slangasek: anyway ticket 1206 is supposed to fix everything and make everybody happy
[04:58] <slangasek> ok, then dropping the testsuite header is correct in that case
[04:58] <slangasek> well, it does not make me happy to have fewer tests ;)
[04:58] <robru> slangasek: it could have been rebuilt in the same old silo instead of force merging but he didn't want to re-qa the whole thing since it was already approved.
[04:59] <robru> slangasek: from what he said it sounded like the tests had no value, or negative value (eg flaky tests that didn't actually test anything meaningful)
[04:59] <robru> slangasek: I can't remember, I think it's in the scrollback in this channel if you look ~5 hours back
[05:02] <slangasek> robru: ok; so I've found the packaging diff and I don't see how Saviq justifies the claim that the tests were no good
[05:02] <slangasek> certainly not to where dropping them is better than keeping them
[05:03] <slangasek> and if we're force-merging because a one-line update to debian/control requires a complete QA re-test, then isn't that a bug in the QA workflow?
[05:04] <robru> slangasek: well if the silo is rebuilt for any reason it clears the qa approval
[05:04] <slangasek> i.e., either a rebuild with no changes to the upstream source requires a full QA retest, or it doesn't - regardless of it's done in this silo or another
[05:04] <robru> slangasek: bileto doesn't know that somethings' being rebuilt for a one line change or even for a no-line change
[05:04] <slangasek> sure
[05:04] <slangasek> but the lander can tell QA, and QA and rubberstamp
[05:04] <robru> right
[05:06] <robru> slangasek: anyway, I think the force-merge is sort of a red herring here, sure it's suboptimal but the real issue is just that you don't approve of the tests being deleted. which I think you should take up with Saviq since I'm not really familiar with why they're being dropped
[05:06] <robru> slangasek: I can't seem to find the message, I thought it was IRC, maybe it was an MP comment or something somewhere
[05:06] <slangasek> robru: no, I don't approve of the tests being deleted, *AND* I don't approve of things being force-merged and left in xenial-proposed
[05:08] <robru> slangasek: I was under the impression that it's ok to force merge when things are stuck as long as people promise to keep an eye on it, and in this case Saviq has a new silo to fix this already prepped, so it seemed ok to me
[05:11] <slangasek> robru: hmm; I wasn't aware that was the accepted practice - at this point in the release cycle, it does mean e.g. release team members going on wild goose chases in update_excuses
[05:13] <robru> slangasek: how does force merge impact release team people? stuff sitting in proposed would look the same to them regardless of if the ticket is merged or not? I don't see the big deal with force merging really since it just means trunk is slightly ahead of distro for a short while. sometimes if there's two conflicting silos and one is being a little slow to
[05:13] <robru> migrate I'll get asked for force merge so that the other silo can be rebuilt sooner, eg, to unblock people wanting to land conflicting silos.
[05:13] <robru> slangasek: it's not an every-day thing but it happens sometimes when people are rushing to get OTAs out the door.
[05:23] <slangasek> robru: hmm, perhaps it's marginal and you should ignore my late-night rant :) but it took extra time to track down the landing because it was force-merged, so it was no longer listed on requests.ci-train.u.c
[05:28] <robru> slangasek: no i think your concerns are justified, there's definitely gaps in the discoverability of information in the system. just needs some iterations here and there
[08:13] <popey> bzoltan: Thanks. i haven't tested a silo for a while, what's the easiest way for me to test that on a device?
[08:15] <bzoltan> popey: I think that /usr/bin/citrain device-upgrade 35 [DEVICE-PASSWORD] is the easiest way
[08:16] <popey> thanks
[08:27] <tvoss> Mirv, for reference: https://code.launchpad.net/~thomas-voss/platform-api/build-modules-as-shared-libraries/+merge/290571
[08:49] <Mirv> tvoss: oh, ok!
[09:02] <popey> bzoltan: jibel silo 35 works for me.
[09:03] <bzoltan> popey: Cool. The Automated Signoff is running, after that i think the packages can be released to xenial  too
[10:10] <bzoltan> jibel: popey: ready to land https://requests.ci-train.ubuntu.com/#/ticket/1202
[10:13] <popey> sweet!, thanks bzoltan
[10:13] <bzoltan> popey:  with pleasure .. nice to fix bugs quickly
[11:20] <popey> bzoltan: i see rvr has a problem with that landing
[11:21] <popey> bzoltan: https://trello.com/c/nGHexJw8/3001-1202-ubuntu-landing-035-ubuntu-ui-toolkit-bzoltan
[11:21] <popey> rvr: any chance you can put videos on people.canonical.com rather that private share, as they're inaccessible to community people. ta
[11:29] <rvr> popey: I have problems accessing people, bad ssh config or something
[11:29] <rvr> I'll try to fix
[11:58] <bzoltan> rvr: popey: is that indicator color issue somehow related to this silo35?
[12:00] <ahayzen> bzoltan, i think Tim's fix was just for MainView's .. that probably comes from Unity8 itself ? I think... and was there before silo035
[12:00] <bzoltan> ahayzen:  indeed
[12:01] <bzoltan> ahayzen: I can spend some time with checking how unity is using palette values, but not with this silo
[12:01] <bzoltan> ahayzen: i would need a day to go thru all the color settings in unity
[12:01] <ahayzen> yeah sounds like a separate issue to this one, silo035 was trying to fix the colours on app launch not todo with the shell
[14:02] <jibel> tvoss, did you publish 33?
[14:03] <tvoss> jibel, nope, do I need to?
[14:03]  * sil2100 is on it
[14:03] <jibel> thanks
[14:03] <sil2100> https://code.launchpad.net/~thomas-voss/location-service/fix-1447110/+merge/289979
[14:03] <sil2100> Needs approval
[14:03] <sil2100> tvoss: ^
[14:03] <tvoss> sil2100, ack
[14:03] <tvoss> ssweeny, mind top-approving: https://code.launchpad.net/~thomas-voss/location-service/fix-1447110/+merge/289979
[14:04] <ssweeny> tvoss, done
[14:04] <tvoss> sil2100, ^
[14:08] <rvr> bzoltan: Silo 35 approved
[14:10] <sil2100> \o/
[14:11] <sil2100> Publishing that as well
[14:25] <sil2100> bzoltan: ^
[14:25] <ahayzen> \o/
[14:25] <sil2100> bzoltan: please review https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fasterWindowColorTrunk/+merge/290458 and https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/cherry_pick-gles/+merge/290461
[14:49] <sil2100> Eh
[14:49] <sil2100> Publishing forcing the unapproved branches
[14:50] <sil2100> We don't have time to spare
[15:04] <tvoss> ssweeny, would you mind if we take https://requests.ci-train.ubuntu.com/#/ticket/1104 prior to your ls landing?
[15:04] <ssweeny> tvoss, go right ahead :)
[15:59] <sil2100> jibel, robru, rvr: I guess we cancel the LT meeting since we have the status meeting at the same time, right?
[15:59] <sil2100> Or maybe we do both at once!
[15:59] <jibel> sil2100, yeah, I didn't plan to attend the landing meeting
[15:59] <jibel> it's a bit redundant
[16:00] <pmcgowan> sil2100, jibel should be quick
[18:11] <pmcgowan> sil2100, whats up with silo 68, its not publishing due excuses
[18:17] <pmcgowan> trainguards can you check silo 68? does someone just need to push it?
[18:18] <robru> pmcgowan: according to britney the android package has unsatisfiable depends but somehow QA approved it anyway.
[18:18] <robru> pmcgowan: but yeah this doesn't block publication, if somebody wants to publish it they can
[18:19] <pmcgowan> robru, this happened with something the other day and we just published
[18:19] <pmcgowan> robru, who can publish it?
[18:19] <robru> pmcgowan: any core dev can do it
[18:19] <pmcgowan> that again :)
[18:20] <pmcgowan> I nominate you for core dev
[18:20] <pmcgowan> mterry, ?
[18:20] <robru> pmcgowan: yeah that's on my to-do list but it's been getting away on me, sorry
[18:20] <robru> ken is mysteriously not here, he's my go-to core dev
[18:21] <mterry> pmcgowan: maybe...?  robru, what's the story with unsatisifable depends?
[18:21] <robru> mterry: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-068/excuses.html but I dunno, i guess android package is special
[18:22] <pmcgowan> mterry, this same thing happened with a silo the other day and ken just pushed it in
[18:22] <pmcgowan> but I dont know why
[18:22] <mterry> the hidden assumption there being that that was the right thing to do?
[18:22] <pmcgowan> seemed to be, somehow ken knew it was bogus, but I really dont know
[18:23] <robru> mterry: I see it this way: this silo isn't actually introducing the unsatisfiable depends (if you look at the diff), so I guess it's a false positive in britney or eg I guess the image builder just pulls it in regardless of the depends or something
[18:24]  * mterry is going throught that silo's packaging diffs and then if nothing crazy, is happy to publish
[18:24] <robru> mterry: yeah you should be reviewing diffs before publishing generally ;-)
[18:24] <dobey> hrmm
[18:24] <robru> mterry: https://requests.ci-train.ubuntu.com/#/ticket/995
[18:25] <dobey> robru: i think it's because the autopkgtests environments don't have multi-arch on maybe? if i install "ubuntu-emulator-runtime" on my machine, it pulls in the :i386 one
[18:25] <mterry> robru: uh.. android-tools-5.1.1r36+git20160322/debian/android-tools-adb.postinst does some crazy stuff, including modifying the current user's (whoever that might be when installing!) ~/.android/adb_usb.ini...
[18:26] <robru> mterry: isn't postinst just run by root?
[18:26] <mterry> robru: if you're running sudo, I'm guessing $HOME is still your user
[18:27] <dobey> eww
[18:27] <dobey> that is nasty
[18:27] <robru> it's clearly just appending device IDs so that they work without clobbering the existing file
[18:27] <mterry> robru: or creating the file
[18:28] <mterry> robru: that's against policy though, to muck with user files.  I think we do it in very few cases.  But usually we have user-migration scripts to do that in a sane way
[18:28] <dobey> and that obviously doesn't help other users on the system who aren't the one running the apt-get install/upgrade
[18:29] <mterry> robru: er session-migration
[18:29] <mterry> robru: This should use a session-migration script, not muck with files directly.  I can't ACK this
[18:30] <robru> mterry: hang on, something funny is going on. I can't find this postinst script in the input mp.
[18:30] <dobey> android-tools isn't managed in launchpad
[18:31] <dobey> the indicator mp obviously won't have it
[18:31] <robru> oh, manual packages. great
[18:31] <dobey> yup
[18:32] <dobey> i don't understand why that wasn't done in a patch though, instead of a hacky postinst
[18:32] <robru> morphis: what's up with android tools? ^^
[18:32] <dobey> the comment even claims the source has some list compiled into the default client; obviously we should be patching that list
[18:34] <mterry> dobey: agreed
[18:34] <dobey> ondra just left though i think
[18:35] <pmcgowan> I don't even think thats true
[18:35] <dobey> which part?
[18:35] <pmcgowan> things work fine without those
[18:35] <pmcgowan> I thought they were added elsewhere
[18:35] <dobey> without the adb_usb.ini ?
[18:35] <pmcgowan> yeah
[18:36] <pmcgowan> BQ and Meizu is not exactly new to us
[18:36] <dobey> oh they were
[18:36] <dobey> +++ android-tools-5.1.1r36+git20160322/debian/patches/add-bq-vendor-id.patch	1970-01-01 00:00:00.000000000 +0000
[18:37] <dobey> so someone needs to regeenrate a source package without the postinst muck, and re-upload to the silo ppa for both xenial/vivid
[18:37] <dobey> (i don't have permissions to upload to the PPA)
[18:38] <pmcgowan> who does?
[18:38] <pmcgowan> I can email ondrej as he said he would be back online later
[18:38] <dobey> i presume robru does. mterry does as well i guess, being a core dev
[18:39] <dobey> mterry: ^^ can you strip that postinst muck out and tweak the version numbers, and re-upload to the PPA?
[18:39] <robru> pmcgowan: yes for silo PPA uploads, it's core devs + me
[18:40] <robru> but best let mterry do it so he can get it just right I think ;-)
[18:40] <mterry> dobey: so...  looks like the old patch got dropped, but the new IDs are still in the merged debian-changes
[18:40] <mterry> dobey: so I agree I'm not sure why the postinst stuff was done...
[18:41] <mterry> pmcgowan: morphis is best to do this, is he not around?
[18:41] <pmcgowan> mterry, dont know we can wait if its best
[18:42] <dobey> probably best to know who did that change exactly, and why
[18:42] <mterry> pmcgowan, robru: this is why I hate this "packaging-ACK" system -- last minute NACKs suck
[18:42] <pmcgowan> indeed
[18:42] <dobey> mterry: agreed
[18:43] <robru> mterry: totally agree, but I can't think of a way to get the ACKs coming sooner. there's no way to stop people making mistakes until they try to publish
[18:43] <mterry> dobey: well....  worst case if we strip out the bogus postinst stuff is that there is some manual config needed on dev machines.  But we won't break anything.  And that can be fixed by future patch...
[18:43] <mterry> robru: unity8 has a merge checklist, one of which is getting a packaging ACK if there are packaging changes.  Hard to FORCE that on other projects, but they should all be doing that
[18:44] <robru> mterry: agreed, should we talk to upper management and get this enforced on all projects? ;-)
[18:44] <dobey> mterry: well, the IDs seem like they are still added. the diff just looks a little weird because the patches all have the source dir with version in them as the reference
[18:44] <dobey> but maybe i read the diff wrong too
[18:44] <dobey> who knows
[18:45] <mterry> dobey: I agree they look like they are still added.  I'm just confused that the postinst stuff was added in first place.  So if our first blushes are correct, removing postinst bits is harmless.  If we're wrong, at worst some devs have to add some manual bits until someone can correct better...
[18:45] <mterry> So I'm just going to do the quick change and hope it is enough
[18:46]  * mterry patches
[18:46] <dobey> mterry: well if the ID patches are required for existing phones, and they are in fact removed, i guess it will break adb for all the current devices too
[18:47] <mterry> dobey: true...  not just dev machines but like all our test tooling  :)
[18:47] <dobey> mterry: but i guess it will be easier to tell if the patches are still there in an unpacked tree, too
[18:47] <mterry> dobey: I'll try it on my phones here at least
[18:47] <dobey> ok
[18:48] <dobey> if krillin still works, i guess it should be good
[18:48] <dobey> robru: fwiw, i /hate/ the checklist thing on unity8
[18:49] <dobey> would be nice to automate most of that work though
[18:51] <mterry> dobey: oh why?
[18:56] <mterry> dobey: ok...  recompiled locally, installed new adb.  did adb kill-server, made sure I didn't have my own ~/.android/adb_usb.ini...  Was able to get into both krillin and arale
[18:56] <mterry> dobey: I guess that's good enough
[19:00] <mterry> robru, pmcgowan: new android-tools for xenial & overlay are building in silo 68
[19:01] <robru> mterry: thanks
[19:01] <mterry> Packaging for everything else seemed fine enough
[19:01] <robru> mterry: right, android was the one blocked by unsatisfiable depends, so that one was ok after all
[19:04] <dobey> mterry: i find the whole concept of "copy and paste this big block of text into your MP and answer all the questions" a bit insulting really.
[19:04] <mterry> dobey: eh I like it as a simple way to avoid forgetting things
[19:05] <mterry> dobey: I'm a forgetful person  :)
[19:05] <dobey> mterry: i like "make check" as a simple way of not forgetting things :)
[19:06] <pmcgowan> mterry, awesome thanks
[19:09] <dobey> i don't know if there are tools for covering all parts of the debian policy, but would be nice to automate some of the stuff that we require a packaging ACK for, when it is possible
[19:10] <mterry> dobey: heh, snapshot the system before, if there are any deltas in $HOME, complain.  Repeat for all possible contents of $HOME  :)
[19:11] <mterry> dobey: or I suppose just grep for ~ or $HOME in a clever way in debian/
[19:11] <dobey> mterry: grep HOME debian/*.postinst seems easier
[19:11] <dobey> heh
[19:12] <mterry> dobey: but you won't catch malicious people assembling variable names out of H, O, M, and E, who just want to write code and hate your checker
[19:12] <dobey> mterry: or encode it into some lintian check if there isn't one already
[19:12] <dobey> well, we should fire those people :P
[19:13] <mterry> dobey: yeah... but how to fire them automatically...?  :P
[19:14] <dobey> mterry: like this: https://www.youtube.com/watch?v=Km6bFBSVty4
[19:15]  * mterry dusts off his fax machine
[19:17] <dobey> i guess we should also maybe have an apparmor rule that prevents dpkg scripts from screwing with $HOME
[19:17] <dobey> whoot
[19:18] <dobey> huh
[19:19] <dobey> mterry: i still see the postinst block in the xenial packaging diff
[19:20] <dobey> err, no
[19:20] <dobey> vivid
[19:20] <dobey> no, both
[19:20] <mterry> dobey: do you see a new changelog entry by me?
[19:20] <dobey> no
[19:20] <mterry> dobey: the packages aren't "published" in that PPA yet
[19:20] <mterry> dobey: I don't know what queuebot is on about
[19:21] <dobey> oh
[19:21] <dobey> hmm
[19:21] <dobey> ah ok
[19:24]  * mterry regenerates silo diffs
[19:26] <mterry> pmcgowan, robru: so I'm guessing you need to re-acquire QA signoff on silo 68?  Probably a quick smoketest to make sure it's still working is enough?  Tell QA folks to rm ~/.android/adb_usb.ini, run "adb kill-server" and then try to adb into their device to confirm the change is OK.
[19:34] <robru> ToyKeeper: jibel: ^
[19:35] <mterry> dobey: chagnes regenerated
[19:35] <pmcgowan> mterry, thanks
[19:36] <dobey> great
[19:37] <pmcgowan> mterry, is the whole silo rebuilding?
[19:37] <mterry> pmcgowan: shouldn't be?  I did a diff-regeneration-only build, but that said it finished
[19:38] <pmcgowan> great
[19:46] <robru> mterry: ok I commented on the ticket & the trello board, hopefully qa notices that soon enough
[20:20] <ToyKeeper> D'oh.  New adb silo isn't done after all?
[20:21] <ToyKeeper> ... and the suggested test will break some other things I have running.  I may want to wait a bit until the other tests finish.
[20:22] <pmcgowan> ToyKeeper, its a "really simple change" but prefer to sanity check
[21:55] <robru> Saviq: if you get a sec pls review https://code.launchpad.net/~robru/qtmir/inline-gles-quilt/+merge/290646
[21:59] <robru> ToyKeeper: "Tell QA folks to rm ~/.android/adb_usb.ini, run "adb kill-server" and then try to adb into their device to confirm the change is OK."