[06:21] <slangasek> mfo: libuv1> a very thorough patch explanation.  Please file this patch upstream in the Debian BTS and adjust the patch header to include Bug-Ubuntu: and Bug-Debian: references (in accordance with https://dep-team.pages.debian.net/deps/dep3/) and I will gladly sponsor
[06:56] -queuebot:#ubuntu-release- Unapproved: cross-toolchain-base (bionic-proposed/main) [25ubuntu6 => 25ubuntu7] (ubuntu-desktop)
[07:03] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross (bionic-proposed/main) [20ubuntu4 => 21ubuntu0.1] (ubuntu-desktop)
[07:04] -queuebot:#ubuntu-release- Unapproved: gcc-8-cross (bionic-proposed/main) [9ubuntu2 => 18ubuntu0.1] (ubuntu-desktop)
[07:06] -queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (bionic-proposed/universe) [6ubuntu3 => 9ubuntu0.1] (no packageset)
[07:15] -queuebot:#ubuntu-release- Unapproved: gcc-defaults (bionic-proposed/main) [1.176ubuntu2 => 1.176ubuntu2.1] (core)
[07:20] -queuebot:#ubuntu-release- Unapproved: gcc-defaults-ports (bionic-proposed/universe) [1.176ubuntu1 => 1.176ubuntu1.1] (no packageset)
[07:56] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (bionic-proposed) [1:6.0.6-0ubuntu<IP_ADDRESS>]
[08:00] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (bionic-proposed) [1:6.0.6-0ubuntu<IP_ADDRESS>]
[08:32] -queuebot:#ubuntu-release- Unapproved: cross-toolchain-base-ports (bionic-proposed/universe) [21ubuntu3 => 22ubuntu0.1] (no packageset)
[09:40] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross (bionic-proposed/main) [20ubuntu4 => 21ubuntu0.1] (ubuntu-desktop)
[09:42] -queuebot:#ubuntu-release- Unapproved: rejected gcc-7-cross [source] (bionic-proposed) [21ubuntu0.1]
[09:45] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross [source] (bionic-proposed) [21ubuntu0.1]
[10:09] <sbeattie> why did golang-1.7 come back into cosmic?
[10:17] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [source] (bionic-proposed) [18ubuntu0.1]
[10:20] <doko> synced?
[10:21] <cjwatson> odd auto-sync / proposed-migration race possibly?
[10:21] <cjwatson> auto-sync doesn't sync previously-removed packages of its own volition
[10:21] <LocutusOfBorg> I think doko did the remove while autosync was running?
[10:22] <cjwatson> could be, should be discoverable from auto-sync logs
[10:24] <LocutusOfBorg> nack, logs seems to be it didn't get autosyncd?
[10:24] <LocutusOfBorg> *say
[10:31] <cjwatson> the LP publication history seems to think auto-sync did it, but I haven't checked in detail
[11:24] <LocutusOfBorg> I see what LP says, but I can't find references here http://people.canonical.com/~ubuntu-archive/auto-sync/2018-05-05/
[11:27] <apw> LocutusOfBorg, that publishing history says it was removed from proposed by britney, removed from release by doko, and copied into release by britney in that order; so think that is an overlap
[11:27] <apw> LocutusOfBorg, the autosync would not necessarily have been that day
[11:34] <LocutusOfBorg> oh... ok
[11:35] <LocutusOfBorg> but I don't get how the same version can be in both pockets at the same time, but I'm not AA and I don't want to know probably :)
[11:35] <apw> a version can be in multiple pockets, that is pretty normal
[11:36] <apw> look at anything in -security and -updates
[11:38] <LocutusOfBorg> yes, but this shouldn't be normal for -proposed and -release, modulo when brintey and publisher are running...
[11:39] <cjwatson> could be while it was running, or could be that the post-move removal failed
[11:39] <cjwatson> *post-copy
[11:39] <cjwatson> the proposed-migration logs should make that clear
[11:53] -queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (bionic-proposed/universe) [6ubuntu3 => 9ubuntu0.1] (no packageset)
[11:54] -queuebot:#ubuntu-release- Unapproved: rejected gcc-8-cross-ports [source] (bionic-proposed) [9ubuntu0.1]
[11:59] -queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu4 => 2.02+dfsg1-5ubuntu4] (core)
[12:07] <mfo> slangasek, thanks for reviewing. sure, the new debdiff in LP now has both Bug-Ubuntu and Bug-Debian tags. o/
[12:08] <mfo> LP #1792647
[12:11] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross-ports (bionic-proposed/universe) [16ubuntu4 => 17ubuntu0.1] (no packageset)
[12:24] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [source] (bionic-proposed) [9ubuntu0.1]
[12:28] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross-ports [source] (bionic-proposed) [17ubuntu0.1]
[13:11] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180510+dfsg1-0ubuntu3~14.04.3 => 20180905+dfsg1-0ubuntu1~14.04.0] (ubuntu-cloud)
[13:11] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20180510+dfsg1-0ubuntu3~16.04.1 => 20180905+dfsg1-0ubuntu1~16.04.0] (ubuntu-cloud)
[13:41] -queuebot:#ubuntu-release- Unapproved: cross-toolchain-base (bionic-proposed/main) [25ubuntu6 => 26ubuntu0.1] (ubuntu-desktop)
[13:42] -queuebot:#ubuntu-release- Unapproved: rejected cross-toolchain-base [source] (bionic-proposed) [25ubuntu7]
[13:59] -queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base [source] (bionic-proposed) [26ubuntu0.1]
[14:00] -queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base-ports [source] (bionic-proposed) [22ubuntu0.1]
[14:02] -queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults [source] (bionic-proposed) [1.176ubuntu2.1]
[14:10] -queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [source] (bionic-proposed) [1.176ubuntu1.1]
[14:14] -queuebot:#ubuntu-release- Unapproved: cross-toolchain-base-ports (bionic-proposed/universe) [22ubuntu0.1 => 22ubuntu0.2] (no packageset)
[14:16] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20180510+dfsg1-0ubuntu4~18.04.1 => 20180905+dfsg1-0ubuntu1~18.04.0] (ubuntu-cloud)
[14:16] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20180510+dfsg1-0ubuntu3~16.04.1 => 20180905+dfsg1-0ubuntu1~16.04.0] (ubuntu-cloud)
[14:18] <mdeslaur> doesn't look like the publisher ran in the past 5 hours, is something wrong? (ie: privoxy in trusty-security isn't showing up...)
[14:18] -queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base-ports [source] (bionic-proposed) [22ubuntu0.2]
[14:19] <mdeslaur> (showing up in http://archive.ubuntu.com/ubuntu/pool/universe/p/privoxy/ , for example)
[14:22] -queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (bionic-proposed) [20180905+dfsg1-0ubuntu1~18.04.0]
[14:37] <infinity> mdeslaur: Publisher has definitely been running.
[14:37] <mdeslaur> infinity: any idea why the binaries aren't showing up?
[14:37] <infinity> mdeslaur: Mirrors could be broken.
[14:38] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20180905+dfsg1-0ubuntu1~18.04.0]
[14:39] <infinity> mdeslaur: Looks like archive frontends haven't updated since 7am UTC.
[14:39] <mdeslaur> hrm
[14:39] -queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (xenial-proposed) [20180905+dfsg1-0ubuntu1~16.04.0]
[14:40] <mdeslaur> infinity: who do I bug about that?
[14:40] <infinity> mdeslaur: Wait, are you in Belgium?
[14:40] <mdeslaur> was just thinking there may be a transparent proxy here
[14:40] <mdeslaur> one sec, looking
[14:40] <infinity> (base)adconrad@nosferatu:~$ host archive.ubuntu.com
[14:40] <infinity> archive.ubuntu.com has address <IP_ADDRESS>
[14:40] <infinity> mdeslaur: ^
[14:40] <infinity> mdeslaur: That's not the real archive. :P
[14:40] <mdeslaur> ARGH
[14:41] <mdeslaur> infinity: sorry for the trouble
[14:44] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1020.21~16.04.1] (no packageset)
[14:51] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1020.21~16.04.1]
[15:08] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20180905+dfsg1-0ubuntu1~16.04.0]
[15:15] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20180905+dfsg1-0ubuntu1~14.04.0]
[15:42] -queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu4 => 2.02+dfsg1-5ubuntu4] (core)
[20:24] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (cosmic-proposed) [2.02+dfsg1-5ubuntu4]
[20:24] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (cosmic-proposed) [2.02+dfsg1-5ubuntu4]
[21:06] <wxl> can anyone explain to me why xfsprogs is not in the lubuntu images? it's in our seeds..
[21:08] <wxl> https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu/tree/live#n32
[21:25] <jbicha> wxl: it's already in https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/tree/live-common#n3
[21:37] <jbicha> you're missing jfsutils too
[21:57] <tsimonq2> Wat. I just looked in debian-cd, ubuntu-cdimage, and livecd-rootfs and I can't find anything.
[21:57] <tsimonq2> infinity, slangasek: Either of you have any ideas? ^
[21:58] <slangasek> have you walked germinate output?
[21:59] <slangasek> and compared build logs?
[22:00] <tsimonq2> I have compared build logs, but I'll look at Germinate now. It seems to be including the live-common seed but for some reason not the packages inside. Peeking at Germinate.
[22:01] <tsimonq2> It's in here: https://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.cosmic/all
[22:03] <tsimonq2> slangasek: Perhaps there's another log file that I'm missing?
[22:06] <slangasek> tsimonq2: the image build logs?
[22:06] <slangasek> those are the ones I meant
[22:10] <tsimonq2> slangasek: There's no output when "Resolving live-common dependencies ..." is outputted, but I also see xfsprogs as being in the "d-i-requirements" file, and with the line "! Duplicated seed: xfsprogs".
[22:10] <tsimonq2> There is no other relevant output it seems.
[22:10] <tsimonq2> (I'm looking at https://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/cosmic/daily-live-20180917.log )
[22:11] <slangasek> isn't this a question of the livefs contents, since it's in the live-common seed
[22:11] <slangasek> ?
[22:11] <slangasek> so you'd need to drill down into the livefs log
[22:11] <slangasek> otherwise I'm afraid I won't be able to help with this now, it's after midnight in local TZ
[22:12] <tsimonq2> Alright.
[22:17] <tsimonq2> slangasek: There doesn't seem to be anything relevant in there either; it would be good to get your thoughts when you wake up.
[22:19] <slangasek> the next thing I would tend to suggest is to look at STRUCTURE to make sure there aren't any differences relative to other flavors that don't have this problem
[22:20] <slangasek> and also probably check if lubuntu-meta needs updating
[22:20] <slangasek> I do see that jfsutils has a task header for all the other live tasks but not for lubuntu
[22:20] <tsimonq2> Already there, and I'll do a quick lubuntu-meta update now to confirm.
[22:20] <slangasek> so archive metadata is wrong, so why
[22:21] <tsimonq2> Which is why my first instinct was to check the tooling for Lubuntu-specific hacks. :P
[22:21] <jbicha> um, check the tasksel package
[22:22] <tsimonq2> Good idea.
[22:28] <jbicha> wxl: I think tasksel not being updated for the new lubuntu is the problem
[23:30] -queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [<IP_ADDRESS>-0ubuntu1]


[00:07] <mwhudson> wgrant: is this the form of replication that lp uses? http://www.postgresql.org/docs/9.1/static/warm-standby.html#STREAMING-REPLICATION
[00:07] <wgrant> mwhudson: Yes
[00:08] <wgrant> It works excellently, though it's somewhat arcane at times
[00:08] <mwhudson> it's postgres, i think that last bit is implied
[00:09] <wgrant> And it's not meant to be possible to demote the master to a slave without rebuilding, but we do it anyway with a bit of evil.
[00:09] <wgrant> Hopefully it'll be a bit better in 9.3, but it works very well once you work it out
[00:09] <wgrant> A tonne less annoying than slony
[00:09] <mwhudson> wgrant: can you restore a slave from a backup that's say about 24 hours old and have it catch up from the master?
[00:10] <wgrant> mwhudson: Um, sort of.
[00:10] <wgrant> It can't be a pg_dump backup
[00:10] <wgrant> It has to be a backup of the raw data files
[00:10] <mwhudson> ah
[00:10] <wgrant> And you have to have WAL retention set high enough
[00:11] <mwhudson> yeah, that last bit was the thing that was starting to scare me a little
[00:11] <mwhudson> well not scare me
[00:11] <mwhudson> intimidate me with the prospect of reading a lot more documentation
[00:11] <wgrant> Once we have enough disk space around we're planning on moving away from pg_dump backups
[00:11] <wgrant> Just rsync the data dir to a backup volume, and keep WAL for weeks
[00:11] <wgrant> Lets you easily bring on a new replica, plus gives you arbitrary PITR for DR.
[00:12] <mwhudson> hmm
[00:12] <mwhudson> hmm
[00:12] <wgrant> For a less insane DB it's probably worth doing both from the start
[00:12] <mwhudson> the reason I'm wondering about this is that i want to move pg off a server temporarily while we upgrade
[00:13] <mwhudson> so maybe i don't need replication at all (a little downtime is ok)
[00:13] <wgrant> Yeah, probably better to take the few minutes of downtime in that case
[00:13] <mwhudson> we could just rsync the data dir from one server to the backup
[00:13] <wgrant> If you have an existing replication setup then sure
[00:13] <mwhudson> stop the db, rsync again, bring up the backup
[00:13] <mwhudson> upgrade the original server
[00:14] <mwhudson> stop the back up pg, rsync back to the original server and start things up again
[00:15] <wgrant> Or just have the service down for the 5 minutes that it takes to upgrade the original server?
[00:15] <mwhudson> wgrant: i mean os upgrade
[00:16] <wgrant> So do I :)
[00:16] <mwhudson> not expecting that to take 5 minutes
[00:16] <mwhudson> hm
[00:16] <wgrant> This isn't Windows or a pandaboard or a desktop, so it should usually be pretty fast, but I guess it depends
[00:18] <mwhudson> I guess i'm a bit paranoid
[00:18] <wgrant> That's always good, but sometimes not justified depending on the particular service
[02:58] <StevenK> wgrant: Does https://code.launchpad.net/~stevenk/launchpad/destroy-pylint-comments/+merge/142053 frighten you?
[03:10] <wgrant> StevenK: Naturally
[03:14] <StevenK> wgrant: Is that code for 'self-review that, damn it' ?
[03:14] <wgrant> No
[03:14] <wgrant> Nearly done
[03:17] <wgrant> StevenK: Done
[03:40] <StevenK> wgrant: Can you glance at the changes in r16406 for that branch to see if I missed something?
[03:41] <wgrant> StevenK: Can you just read through the new revision diffs and remove the many comments that are now obsolete?
[03:42] <StevenK> I already did that before commiting, I'm wondering if I missed something
[03:42] <StevenK> r16406 only changed 36 files
[03:43] <wgrant>  # A zope interface doesn't have self as a parameter for its methods.
[03:43] <wgrant> - # pylint: disable-msg=E0211
[03:43] <wgrant>  # This class should know about the private _window attribute.
[03:43] <wgrant> - # pylint: disable-msg=W0212
[03:43] <wgrant>  # We are deliberately not calling PullerWorkerProtocol.__init__:
[03:43] <wgrant> - # pylint: disable-msg=W0231
[03:43] <wgrant>  # We know we are not using dirnames.
[03:43] <wgrant> - # pylint: disable-msg=W0612
[03:43] <wgrant>  # The super constructor is a no-op.
[03:43] <wgrant> - # pylint: disable-msg=W0231
[03:44] <wgrant> - # pylint thinks this raises None, which is clearly not
[03:44] <wgrant> - # possible. That's why this test disables pylint message
[03:44] <wgrant> # E0702.
[03:57] <StevenK> wgrant: So it seems getUtility(IPackageDiffSet).getDiffsToReleases(sprs, preload_for_display=True) preloads the LFAs and LFCs, but the page goes ahead and queries again anyway. Surely it should be cached since it's just a key lookup?
[03:58] <wgrant> StevenK: Right, you'll need to work out why they're not
[04:03] <StevenK> Hmm, looks like the LFA ids are not the ids from the packagediff query
[04:03]  * StevenK peers closer
[04:06] <StevenK> (Pdb) lfa.filename
[04:06] <StevenK> u'filename-100051'
[04:06]  * StevenK facepalms
[04:09] <wgrant> Hmmmm?
[04:10] <StevenK> I'm poking around in the DB for that id, so I can work out what it is
[04:10] <StevenK> It isn't a SPRF, BPF or a PackageDiff
[04:10] <wgrant> Ah
[04:10] <wgrant> Check the traceback on the query?
[04:11] <StevenK> The test isn't giving a traceback
[04:12] <wgrant> If it's a query count test then the statement collector will have tracebacks
[04:12] <StevenK> AH HA
[04:13] <StevenK> It's the files from the PUCs
[04:19] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bfj-mixin/+merge/142055
[04:21] <StevenK> 170+class TestBuildFarmJobBase:
[04:21] <StevenK> And then you call super() ?
[04:22] <wgrant> I didn't write that, but yes, it's fine to call super() in a class with no superclasses
[04:22] <wgrant> Because of multiple inheritance, there still may be classes further up the MRO
[04:23] <wgrant> Otherwise if I inherit from (TestBuildFarmJobBase, TestCaseWithFactory) it might not go all the way up
[04:23] <StevenK> 417# The url of the upload log file is determined by the PackageBuild.
[04:23] <StevenK> That comment is sort of wrong now, no?
[04:24] <wgrant> The tests are all very strange now
[04:24] <wgrant> I just needed them to pass
[04:24] <wgrant> They'll obviously need to be significantly reworked over the next couple of days when PackageBuild and BuildFarmJob cease to exist :)
[04:24] <StevenK> Yeah
[04:25] <StevenK> Niggle dropped, since you'll need to revisit the tests, r=me
[04:25] <wgrant> Thanks
[04:50] <wgrant> StevenK: Why's the invalidate in getDiffTo?
[04:50] <StevenK> Because that creates a PackageDiff?
[04:50] <wgrant> No
[04:50] <wgrant> That's a selectOneBy
[04:51] <wgrant> You might mean requestDiffTo
[04:51] <StevenK> Yeah, I've just shifted it
[04:51] <wgrant> Great
[04:51] <StevenK> Any other issues?
[04:52] <wgrant> Doesn't look like it
[04:52] <wgrant> Does it work?
[04:52] <wgrant> Have you tested the query count on DF?
[04:53] <StevenK> I've seen appreciable drops in the query count from the tests
[04:53] <StevenK> I can cowboy it onto DF
[04:53] <wgrant> Right, but it's worth a cowboy to see that you've actually caught everything
[05:22] <StevenK> wgrant: +queue ==  At least 56 queries/external actions issued in 0.99 seconds
[05:22] <wgrant> StevenK: Checked various Done pages?
[05:22] <StevenK> Just loading Done
[05:22] <StevenK> Which timed out
[05:23] <StevenK> At least 66 queries/external actions issued in 12.24 seconds
[05:24] <wgrant> What are the extra 10?
[05:24] <StevenK> Reload gets us to 3.26
[05:25] <StevenK> wgrant: Checking the query log without JS?
[05:25] <StevenK> You evil man
[05:25] <wgrant> Because Firefox and Chromium have become stupid, you might need to select the entire page content and View Selection Source
[05:25] <wgrant> Because View Source seems to reload the page without cookies
[05:27] <StevenK> Ugh
[05:32] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/minimise-bfj-interfaces/+merge/142058
[05:33] <bigjools> wtf does view source even reload the page ...
[05:33] <wgrant> It's possible that IPackageBuildDB will need build_farm_job_id, but I don't think so
[05:33] <wgrant> bigjools: Probably because LP sets no-cache, and browsers are retarded
[05:33] <wgrant> Although do we actually set no-cache nowadays...
[05:34] <StevenK> Items in the NEW queue have no SPRs and so a portition of the preloading is skipped?
[05:36] <wgrant> They have SPRs
[05:36] <wgrant> But no SPPHs
[05:36] <wgrant> But +queue shouldn't care about SPPHs except for detecting newness
[05:36] <StevenK> Ah ha
[05:37] <StevenK> No binaries for source in NEW
[05:39] <StevenK> wgrant: http://pastebin.ubuntu.com/1505886/ is a diff between the queries
[05:39] <StevenK> Between the query logs, even
[05:41] <wgrant> Well
[05:41] <wgrant> Obvious one is sections
[05:41] <wgrant> Are you failing to preload binary sections, perhaps?
[05:41] <StevenK> I don't grab bprs at all, so likely
[05:45]  * StevenK shovels more coal into mawson
[05:46] <wgrant> While you're waiting for it to run 'bzr st' you can review my branch :)
[05:46] <StevenK> I have
[05:46] <wgrant> Oh, so you have
[05:47] <wgrant> StevenK: Hideous!?
[05:47] <StevenK> Right, NEW is now 58, and DONE is 62.
[05:47] <wgrant> We only have IBuildFarmJob, IBuildFarmJobOld and IBuildFarmJobDB
[05:47] <wgrant> I don't know WHAT you are talking about
[05:47] <wgrant> What did you change?
[05:49] <StevenK> load_referencing(BPR) and load Section for sprs + bprs
[05:51] <StevenK> wgrant: I can diff the query logs again if you wish
[05:52] <wgrant> Aha
[05:52] <wgrant> Are you sure the BPRs weren't already loaded somewhere?
[05:52] <wgrant> It already preloads the BPFs
[05:52] <wgrant> Possibly directly
[05:53] <wgrant> It may be worth replacing that prejoin
[05:53] <StevenK> That's inside the browser code, I can rip that out if you wish
[05:53] <StevenK> But it's a bit disgusting and it links into CPU
[05:53] <StevenK> So I'm hoping I can leave it alone
[05:54] <StevenK> Or I could just preload the BPR sections in the browser code
[05:55] <wgrant> Well, SQLObject prejoins are thoroughly deprecated anyway, so it'd be nice to eliminate it if it's easy
[05:56] <wgrant> And I suspect it would be cleaner given all the other preloading you're doing now
[05:56] <StevenK> It's calling into IBinaryPackageFileSet.getByPackageUploadIDs
[05:56] <wgrant> Oh god why
[05:56] <wgrant> It may be worth eliminating that method
[05:56] <wgrant> Rather than double-querying the BPrs
[05:57] <wgrant> (Since that obviously joins through them, though it might not actually grab them)
[05:57] <StevenK> browser/queue is the only callsite
[05:57] <StevenK> And some hideous doctest
[05:57] <wgrant> Kill
[05:57] <wgrant> Crush
[05:57] <wgrant> Destroy
[05:57] <StevenK> WITH FIRE
[06:05] <StevenK> wgrant: Haha, IBinaryPackageFileSet and ISourcePackageReleaseFileSet only have stuff used by that page
[06:05] <StevenK> So I can delete the whole interface and model classes
[06:06]  * wgrant loses
[06:06] <wgrant> Excellent
[06:33] <StevenK> NEW = 65 and DONE = 72
[08:20] <wgrant> StevenK: Nice easy one if you're still around: https://code.launchpad.net/~wgrant/launchpad/no-+buildjob-redirect/+merge/142066
[08:46] <StevenK> wgrant: Was distracted by Orks in SM, but r=me
[08:52] <wgrant> Thanks
[14:34] <czajkowski> mgz: best place to send someone intersted in bzr community disucssions?
[15:24] <mgz> czajkowski: the mailing list?
[15:26] <czajkowski> mgz: ah yes what is the sign up page for that
[15:26] <czajkowski> it's not n the signature of the list
[15:26] <mgz> it's on lists.ubuntu.com
[15:26] <mgz> linked from the main page
[15:29] <czajkowski> ah
[15:29] <czajkowski> cheers
[19:58] <dobey> anyone have any idea what might cause the dailydeb issues happening in https://launchpadlibrarian.net/127602321/buildlog.txt.gz ? running dailydeb locally works fine (save for my needed to use debupstream instead of debversion, otherwise it fails immediately on that)
[19:58] <dobey> #launchpad seems dead, so asking here
[20:57] <czajkowski> abentley: allenap gary_poster ^^^
[21:02] <abentley> czajkowski: Sorry, don't know.
[22:33] <gary_poster> czajkowski, I have no idea I'm afraid.
[23:11] <hloeung> morning
[23:12] <czajkowski> hloeung: ello


[00:24] <wgrant> cprov: https://code.launchpad.net/~wgrant/launchpad/unicode-diff-comments/+merge/219622
[00:52] <cprov> okay, let's do it
[00:55] <wgrant> cprov: https://plus.google.com/hangouts/_/76cpjr00m1nqltssq00re4q8sg when you're ready
[04:06] <cprov> wgrant: ping
[04:07] <wgrant> cprov: Hi
[04:07] <wgrant> I'm half-way through the review
[04:07] <cprov> wgrant: cool, thx
[09:19] <cjwatson> wgrant: Any luck with the livefs review?  (Should I arrange to be in the Soyuz call tonight?  I've lost track of what timezone it's in)
[09:19] <cjwatson> I've just got the cdimage bits working end-to-end, albeit hackily
[09:21] <wgrant> cjwatson: Sorry, been busy with other stuff... possibly tomorrow, though more likely next week.
[09:21] <wgrant> I think the call is 22:00 atm, but I'm not sure we have much to discuss.
[09:24] <jtv> Hi cjwatson, hi wgrant.
[09:24] <wgrant> Evening jtv.
[09:25] <jtv> Spent some time with Adam last week reminiscing about how much slower the publishing cycle used to be...  The optimisation work is really appreciated.
[09:25] <jtv> (Yes I know, that's a long time ago.  But it's also nice to hear that the benefits of what we do lasts, isn't it?)
[09:34] <wgrant> Yeah, it's a little bit better now.
[09:36] <jtv> Didn't it go from struggle-to-keep-it-under-an-hour to let's-do-another-one-in-the-time-left?
[10:55] <cjwatson> I must say this font change is a noticeable improvement.
[10:56] <cjwatson> jtv: I think we average about four an hour.
[10:57] <cjwatson> It's not necessarily predictable, but usually that doesn't matter :)
[13:12] <cjwatson> wgrant: How might I QA https://code.launchpad.net/~cjwatson/launchpad/copy-errors-to-sponsored/+merge/219666 ?  The obvious ways I can think of don't send mail
[13:25] <wgrant> cjwatson: Which don't send mail?
[13:25] <wgrant> The stagings (inc. dogfood) send mail, but it all goes to one mailbox.
[13:25] <cjwatson> I don't see anything in /srv/launchpad.net/launchpad_mailqueue, which is what labbu:/srv/launchpad.net/codelines/current/production-configs/dogfood/mail-configure-normal.zcml declares
[13:27] <wgrant> cjwatson: That's a temporary mailbox which is flushed at the end of the request.
[13:27] <wgrant> If it's even still used at all.
[13:27] <wgrant> You don't know about<EMAIL_ADDRESS>[13:28] <cjwatson> I think I've seen mention of it but have no idea how I'd access it
[13:28] <wgrant> cjwatson: Normal IMAP server, username staging, password somewhere.
[13:28]  * wgrant finds password
[13:29] <cjwatson> Ah.  Maybe I'd better move back inside then in order to be on a proper-ish network
[13:29] <wgrant> Oh yeah
[13:29] <wgrant> I should probably do this for you
[13:29] <wgrant> Though your connection is probably about as good as mine to the UK.
[13:29] <cjwatson> Oh?
[13:29] <wgrant> The inbox will probably have literally a million messages in it atm.
[13:30] <cjwatson> Oh, right.  I can probably fire up a client on chiark if that's OK.
[13:30] <cjwatson> If I can remember the rune to stop mutt sorting the mailbox on entry
[13:31] <wgrant> I'd really prefer that random unowned machines didn't have this sort of password, but perhaps :)
[13:33] <wgrant> If the IMAP server wants to respond to my request to open the mailbox...
[13:33] <cjwatson> Well, my own network might cope
[13:33] <cjwatson> I can certainly try
[13:37] <wgrant> It might need IS intervention to clear out some of the contents.
[13:37] <wgrant> I'm not sure if grenadilla is going to reply.
[13:38] <StevenK> wgrant: Even with running purge-mail first?
[13:39]  * cjwatson finds the relevant wiki.c.c page
[13:43] <cjwatson> Heh, "mailbox is locked", I guess it's at least trying to respond to wgrant
[13:43] <cjwatson> Oh, there we go, fetching headers when I try in read-only mode
[13:45] <wgrant> StevenK: It's purge-mail's login attempt...
[13:45] <wgrant> It's logged in now; took about 10 minutes
[13:47] <StevenK> Niiiice
[13:48] <wgrant> imaplib.abort: command: STORE => socket error: EOF
[13:48] <wgrant> Still, one batch of deletions got through.
[13:49] <wgrant> And it seems faster now.
[13:49] <wgrant> Only a few seconds to log in.
[13:51] <StevenK> I suspect the mailbox has been re-indexed and the inodes are in RAM
[13:51] <wgrant> Yeah, it's deleting reasonably quickly now.
[13:55] <wgrant> cprov: http://people.canonical.com/~wgrant/launchpad/mp-edit-icon.png has some CSS changes I'm playing with.
[13:56] <cprov> nice!
[13:57] <wgrant> It looks a bit less crazy when you don't have a couple of comments for each line.
[13:57] <wgrant> But the comments are more obvious now, and the edit icon appears on <tr> hover
[13:58] <cprov> eheh, but that's how it will look like in real life scenario
[13:58] <wgrant> The editor is invoked by double-clicking on the line, or single clicking on the line number.
[13:58] <wgrant> cprov: Can you look at https://code.launchpad.net/~wgrant/launchpad/unicode-diff-comments/+merge/219622?
[13:59] <cprov> sure, in a bit
[14:18] <cjwatson> wgrant: I guess your script only expunges in one go at the end?  mutt still wants to load 925000-odd messages.
[14:18] <cjwatson> (or headers for them, anyway)
[14:19] <wgrant> cjwatson: It's still going.
[14:19] <wgrant> There may be that many left
[14:20] <cjwatson> It hasn't changed in some time.
[14:22] <wgrant> Ah, maybe then.
[14:33] <cprov> wgrant: you can land the rc unicode mail fixing branch, then we can rollout ... is there anything else worth waiting ?
[14:35] <wgrant> cprov: I think that's a good plan. I've just send it off to PQM; can you deploy when it's done?
[14:36] <cprov> wgrant: sure thing
[14:36] <wgrant> Thanks.
[15:16] <wgrant> cjwatson: Inbox looks slightly cleaner now.
[15:16]  * wgrant wanders off
[15:18] <cjwatson> wgrant: Great, thanks.  You sure dogfood sends stuff there?  I'm not seeing it if so
[16:20] <cjwatson> wgrant: Never mind, I managed to QA it on staging.
[23:40] <wgrant> cjwatson: Dogfood's meant to :/
[23:43] <cjwatson> Yup.  Fairly clearly didn't.
[23:44] <cjwatson> Firewall maybe?
[23:44] <cjwatson> files/firewall/lutin/lan_to_net.sh seems to accept only asuka, loganberry, gandwana.
[23:45] <wgrant> labbu and arsenic are on the same LAN
[23:46] <cjwatson> labbu and grenadilla aren't though?
[23:46] <cjwatson> Or is it meant to relay through arsenic?
[23:47] <wgrant>   driver = manualroute
[23:47] <wgrant>   domains = ! +local_domains
[23:47] <wgrant>   transport = rewrite_smtp
[23:47] <wgrant>   route_list = * arsenic.canonical.com
[23:48] <wgrant> It forwards everything arsenic, which rewrites it to<EMAIL_ADDRESS>[23:53] <cjohnston> wgrant: is http://bazaar.launchpad.net/~canonical-ci-engineering/uci-engine/trunk/revision/483 503ing for you as well?
[23:54] <cjwatson> it did but works for me now
[23:54] <wgrant> Weird.
[23:55] <cjohnston> hrm
[23:55] <cjwatson> (I loaded a different URL on bazaar.launchpad.net in between; shouldn't matter, but ...)