[00:00] <wgrant> Just make sure lucid-lp-base isn't running while the clones are.
[00:00] <wgrant> Doesn't matter wth the btrfs variant, but for aufs it does.
[00:00] <wgrant> Also, it needs to have your SSH key in authorized_keys, as you may be able to tell.
[00:03] <wgrant> There's probably some huge piece I've completely forgotten, but hunting for that can happen tomorrow.
[00:09] <LPCIBot> Project db-devel build #676: FAILURE in 5 hr 48 min: https://lpci.wedontsleep.org/job/db-devel/676/
[00:09] <lifeless> wgrant: well, I am probably going to keep 100GB or so of windows around Just In Case
[00:10] <lifeless> I'm assuming dmraid will handle the dell raid setup
[00:10] <wgrant> Bah.
[00:10] <wgrant> Possibly.
[03:21] <lifeless> mwhudson: you have a sandybridge machine right ?
[03:38] <mwhudson> lifeless: i do
[03:50] <lifeless> did you have any issues with the natty desktop cd ?
[03:50] <lifeless> I get the fine grey crosshatch and nothing more
[03:53] <mwhudson> lifeless: no, installation went absurdly smoothly
[04:09] <LPCIBot> Yippie, build fixed!
[04:09] <LPCIBot> Project devel build #846: FIXED in 5 hr 29 min: https://lpci.wedontsleep.org/job/devel/846/
[05:42] <lifeless> mwhudson: interestingly, its happy with lcd, but it hated my analogue monitor.
[05:42] <mwhudson> lifeless: heh
[05:43] <lifeless> 50% of my desktop backed up
[05:43] <mwhudson> lifeless: i've tested mine with a projector over vga and that worked
[05:43] <mwhudson> (post-install)
[05:43] <lifeless> mwhudson: this has a non-intel graphics card in it, for additional fun
[05:43] <lifeless> being a desktop and all
[05:44] <mwhudson> ah ok
[05:44] <mwhudson> well i can't help you with that then :)
[05:45] <lifeless> :)
[06:00] <LPCIBot> Yippie, build fixed!
[06:00] <LPCIBot> Project db-devel build #677: FIXED in 5 hr 51 min: https://lpci.wedontsleep.org/job/db-devel/677/
[06:26] <lifeless> jml: https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements#preview
[09:06] <wgrant> bigjools: Any objections to my comments on bug #797599?
[09:07] <_mup_> Bug #797599: Copying archivepermissions cross-distro is wrong. <derivation> <qa-untestable> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/797599 >
[09:07] <bigjools> wgrant: I don't see any comments from you
[09:09] <wgrant> bigjools: Packagesets are per series.
[09:09] <wgrant> bigjools: So after duplicating the sets we need to regrant permissions.
[09:09] <StevenK> Why did that just get removed? It's trivial to fix.
[09:09] <wgrant> launchpad_dev=# \d packageset
[09:09] <wgrant> [...]
[09:09] <wgrant>  distroseries    | integer                     | not null
[09:12] <wgrant> abentley: You has QA.
[09:12] <bigjools> wgrant: RARGH
[09:12] <StevenK> Haha
[09:12] <StevenK> That's my line.
[09:12] <wgrant> bbiRargh?
[09:12] <wgrant> Er.
[09:12] <wgrant> bigjools: Rargh?
[09:13] <bigjools> having to re-init *archive* level permissions on a new series is crack
[09:13] <wgrant> Well.
[09:13] <bigjools> the model is broken
[09:13] <wgrant> Yes.
[09:13] <wgrant> Sort of.
[09:13] <wgrant> Packagesets have to be per-series.
[09:13] <bigjools> I know
[09:13] <wgrant> So permissions based on them have to be.
[09:13] <bigjools> the FK is wrong
[09:13] <wgrant> How?
[09:13] <wgrant> Well, how would it be improved?
[09:13] <bigjools> NFI ATM
[09:13] <wgrant> Besides nuking from orbit.
[09:13] <wgrant> Right.
[09:14] <wgrant> Exactly.
[09:14] <bigjools> need to think about it
[09:14] <bigjools> but not in a plenary!
[09:14] <wgrant> True.
[09:14] <wgrant> I won't roll it back for now, but will file a critical regression bug.
[09:14] <bigjools> that's fine, we can fix it
[09:14] <bigjools> next week
[09:16] <lifeless> morning d'blin
[09:16] <wgrant> Hi lifeless.
[09:17] <lifeless> apparently dmraid doth not split IO across underlying devices
[09:17] <lifeless> this saddens me
[09:17] <wgrant> Yay!
[09:17] <wgrant> Fakeraid must die.
[09:17] <StevenK> wgrant: Including MD?
[09:18] <lifeless> wgrant: its not substantially different to mdraid other than needing to match BIOS supported layouts, *and* being able to boot sanely.
[09:18] <StevenK> And wgrant has the deployment report open. Who would have thunk it.
[09:18] <lifeless> wgrant: i like being able to boot sanely.
[09:19] <StevenK> lifeless: Er? GRUB2 can boot off RAID
[09:19] <lifeless> StevenK: last I saw it requires the device to be on a single disk, because its not actually bringing up all the layers
[09:19] <lifeless> its essentially running in degraded form
[09:20] <StevenK> lifeless: My fileserver boots off RAID1 just fine
[09:20] <lifeless> this means it won't work for anything other than a vanilla mirror
[09:20] <StevenK> But I can't check, since my home DSL is down.
[09:20] <lifeless> StevenK: e.g. vanilla mirror
[09:20] <StevenK> You're closer, so go check. :-P
[09:20] <lifeless> StevenK: ring your wife :)
[09:20] <wgrant> StevenK: MD is not fakeraid.
[09:20] <wgrant> It's software RAID.
[09:20] <lifeless> wgrant: so is fakeraid
[09:21] <wgrant> It is, but with an extra layer of proprietary crap.
[09:21] <lifeless> wgrant: its really not that proprietary.
[09:21] <lifeless> crappy docs though
[09:21] <wgrant> Stupid and pointless and non-standard, then.
[09:21] <lifeless> wgrant: what would make it a standard?
[09:21] <wgrant> Not being chipset-dependent.
[09:21] <StevenK> It mainly exists because versions of Windows didn't do RAID, right?
[09:22] <lifeless> StevenK: *booting* from RAID requires either fragile gymnastics or a BIOS (or lower) support for the raid layout
[09:23] <lifeless> StevenK: the ICH (and similar) raid implementations exist because controller cards that have ATAPI/SCSI on the topside and N disks on the bottom side are hugely expensive for entry-level environments, and *other* than such cards ... you had to do gymnastics
[09:24] <lifeless> so fakeraid does *exactly* what the early boot BIOS interrupt calls do for SCSI and IDE disks, and run just long enough to let the OS load its drivers.
[09:25] <lifeless> if fakeraid is stupid, so is being able to boot off of IDE and SCSI disks.
[09:30] <gmb> wgrant: Is it possible to set append-revisions-only on an existing branch? I can only find references to it on bzr init.
[09:31] <wgrant> gmb: You probably have to edit .bzr/branch/branch.conf using something like hitchhiker.
[09:31] <wgrant> bzr reconfigure doesn't seem to have an option.
[09:32] <gmb> wgrant: Ah, right, thanks.
[09:32] <wgrant> Just add a line with 'append_revisions_only = True' to branch.conf
[09:37] <maxb> You can use bzr config now to set append_revisions_only
[09:37] <wgrant> Ahh, true.
[09:37] <wgrant> Forgot about the new shiny.
[09:43] <StevenK> LIFELESS!
[09:43] <StevenK> RARGH
[09:43] <wgrant> StevenK: Oh?
[09:44] <StevenK> parellel-test #80 has been building for *13* hours
[09:45] <wgrant> Heh.
[09:46] <StevenK> hudson   25142  0.0  0.0      0     0 ?        Z    Jun28   0:14 [/usr/bin/python] <defunct>
[09:46] <StevenK> ORSUM
[09:47] <StevenK> wgrant: Shall I kill it with fire?
[09:54] <lifeless> jml: hi
[09:54] <lifeless> jml: I've put some prose into the servicesrequirements page
[09:54] <jml> lifeless: yeah, I saw, thanks.
[09:54] <jml> lifeless: will look soon.
[09:54] <lifeless> I think it captures all that we spoke about, and includes sufficient rationale
[09:54] <lifeless> jml: if it doesn't, please fix-or-tell-me
[09:54] <lifeless> ?
[09:56] <nigelb> StevenK: heh, weren't you about to kill all of windmill with fire? :)
[09:56] <nigelb> *windmill tests
[09:57] <LPCIBot> Project parallel-test build #80: ABORTED in 12 hr: https://lpci.wedontsleep.org/job/parallel-test/80/
[09:57] <StevenK> DIE, FIEND
[09:58] <nigelb> lol
[09:58] <jml> lifeless: ok, will do.
[09:59] <StevenK> nigelb: parallel-test has nothing to do with Windmill.
[09:59] <nigelb> StevenK: ah!
[09:59] <nigelb> One of my merge requests has become sort of stale.  Before I work on that branch, I want to "rebase" it wth master
[09:59] <nigelb> is there a bzr equivalent of that?
[10:00] <nigelb> (this is an LP merge proporsal that I need to finish working on)
[10:00] <StevenK> Don't rebase, just bzr merge devel in
[10:01] <jml> lifeless: any ideas for useful LP (or related) hacking for me this week?
[10:01] <wgrant> lifeless: :( resetting rabbit is hard.
[10:02] <lifeless> jml: just about anything is useful
[10:02] <StevenK> wgrant: Do you think there is any point to keeping the windmill-{db-,}devel jobs on Jenkins, or shall I delete them?
[10:02] <wgrant> StevenK: I'd keep them for now, just in case. It is cheap...
[10:02] <lifeless> jml: one thing that you and I probably have most experience around is getting the test suite to stop stomping on stdout when something goes wrong
[10:02] <jml> lifeless: yeah, I know. that's largely the problem :D
[10:02] <lifeless> jml: that messes up subunit
[10:02] <nigelb> er, I did "bzr merge ../devel" and now it seems to have just gotten stuck
[10:03] <jml> lifeless: yeah, ok, I could try with that.
[10:03] <StevenK> nigelb: Is devel up-to-date?
[10:03] <nigelb> doesn't merge give me feedback on stdout on what's going on?
[10:03] <nigelb> StevenK: yeah
[10:03] <nigelb> oh
[10:03] <nigelb> done :D
[10:03] <StevenK> Heh
[10:03] <stub> I always wanted to make tests fail that spat stuff out to stdout or stderr
[10:03] <StevenK> More patience required
[10:03] <stub> Not sure the most bulletproof method of doing that though
[10:03] <jml> stub: interestingly, the way we patch the login object practically guarantees that tests will
[10:04] <nigelb> Sadly, I can't apt-get install patience :)
[10:04] <StevenK> I'd like to see an option to bin/test that will stop spewing the librarian log out on test failure
[10:04] <lifeless> deprecation warnings and bzr's __del__ methods are particularly hard to get at to fix this
[10:04] <lifeless> StevenK: its an attachment to the test
[10:04] <lifeless> StevenK: something you could do that is better
[10:04] <lifeless> StevenK: would be to teach the layer to only attach the *per-test* component of the log
[10:04] <lifeless> StevenK: rather than the log-since-fixture-start.
[10:05] <lifeless> StevenK: e.g. truncate the log or record the position or whatever in the layer per test setup
[10:05] <lifeless> StevenK: if you use tribunal though,t he librarian log won't be in your face anyway
[10:05] <spiv> lifeless: most of bzr's __del__ methods are being deleted.
[10:05] <lifeless> spiv: I know :)
[10:05] <lifeless> spiv: (and I'm glad)
[10:05] <StevenK> lifeless: Bleh, more reason to learn tribunal
[10:06] <nigelb> wow, I updated my devel again.
[10:06] <nigelb> Lots of deletions \o/
[10:07] <StevenK> % apt-cache search tribunal | wc -l
[10:07] <StevenK> 0
[10:07] <nigelb> I guess that's the windmill being burned with fire.
[10:07] <StevenK> jml killed lots of line too
[10:07] <lifeless> StevenK: poolie: can get you going with tribunal
[10:07] <nigelb> I now realzie I'm going to fix the same bug 4 times.
[10:08] <_mup_> Bug #4: Importing finished po doesn't change progressbar <lp-translations> <Launchpad itself:Fix Released by carlos> <Ubuntu:Invalid> < https://launchpad.net/bugs/4 >
[10:08] <lifeless> StevenK: it has testr integration, so its basically just tribunal .
[10:08] <StevenK> I don't have testr either ...
[10:08] <lifeless> StevenK: that one is packaged; shiniest version is in the testing cabal ppa, but the one in natty is eminently usable
[10:11] <wgrant> lifeless: It seems there is no way to list all rabbitmq queues without using rabbitmqctl, which is 100-200ms :(
[10:11] <wgrant> lifeless: Which makes fixture reset difficult.
[10:13] <lifeless> wgrant: :(
[10:13] <lifeless> wgrant: there are some alternatives
[10:14] <wgrant> Creating a new vhost is also 100-200ms.
[10:14] <wgrant> Seems to be erlang startup.
[10:14] <lifeless> wgrant: such as, use the in python api to note queue access and connect-and-flush-all-those at the end of the test
[10:15] <wgrant> lifeless: Yeah, possibly...
[10:15] <wgrant> lifeless: But that becomes really bad when we have multiple consumers.
[10:15] <wgrant> That we don't control.
[10:15] <lifeless> wgrant: for an LP test run, all consumers should be test fakes
[10:16] <lifeless> wgrant: which means we have a testing interface to them, and can tell them to do their own reset dance
[10:16] <wgrant> "should"
[10:16] <lifeless> wgrant: the page has been changed.
[10:16] <wgrant> Also, I am talking about now.
[10:16] <wgrant> Not in two years.
[10:16] <lifeless> wgrant: *must*, or it can't go live. Existing things like the librarian are excluded
[10:16] <wgrant> Hmm.
[10:17] <lifeless> I'm flexible on this, but I think that being waffly would make it harder for folk to design well
[10:17] <lifeless> so I've stopped waffling on this aspect.
[10:19] <lifeless> by flexible I mean I am willing to be wrong and discuss; however your objection seemed to be that there was no requirement so we would have trouble in the future.
[10:20] <StevenK> abentley: Can haz QA? And not submitting branches with [r=me] ?
[10:20] <wgrant> Well, I told him to verbally, but I didn't think he'd take it literally :)
[10:21] <lifeless> StevenK: do you mean 'please use r=<ownname> rather than r=me when self reviewing' ?
[10:21] <lifeless> StevenK: if so, +1
[10:22] <StevenK> r=me or rs=me is so pointless it may as well not be there.
[10:22] <StevenK> Since loggerhead on devel won't tell us who commited it
[10:23] <StevenK> Which means you either need to know, or ask buildbot. And asking buildbot makes me sad.
[10:23] <wgrant> Or check the committer of the merge revs.
[10:27] <wgrant> lifeless: Hmm, FixtureResource doesn't use reset()?
[10:32] <wgrant> The rabbitmq management plugin does what we want, but the rabbitmq plugin build system seems to be designed primarily to make people want to die.
[10:32] <lifeless> ha. headdesk. ha.
[10:32] <StevenK> 103 files mention 'unseen' -- some would be false-positives
[10:34] <wgrant> Perhaps we should use carrot.
[10:35] <wgrant> (it has a memory-based backend, as well as a rabbit one)
[10:36] <wgrant> Which would allow us to do unit tests with a nice fake.
[10:54] <lifeless> wgrant: that only helps if we're not talking to a microservice
[10:59] <Riddell> simple review needed https://code.launchpad.net/~jr/launchpad/797688-packaging-branches-label
[11:04] <StevenK> Riddell: I'd like to see some test changes, to be honest.
[11:06] <benji> someone asked about this yesterday and I wan't yet aware that it existed: http://ricostacruz.com/js2coffee/
[11:07] <lifeless> benji: wicked
[11:10] <benji> poolie: this just came up on my feeds and wondered if you'd seen it: https://www.mergebox.net/
[11:10] <benji> they bill themselves as the GitHub of bzr
[11:11] <lifeless> benji: they announced themselves on the bzr dev list
[11:11] <lifeless> benji: very interesting project
[11:12] <benji> ahh, I should have figured they would engauge in some way
[11:12] <lifeless> not at all
[11:12] <lifeless> its good to raise interesting things
[11:12] <wgrant> lifeless: Sure.
[11:23] <LPCIBot> Project parallel-test build #81: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/parallel-test/81/
[11:33] <lifeless> usb2 is so slow!
[11:33] <wgrant> bigjools: It is the 'ppa' name.
[11:33] <wgrant> bigjools: Not 'Test'
[11:33] <wgrant> So it's not quite so easy.
[11:34] <bigjools> yeah just saw
[11:51] <LPCIBot> Project db-devel build #678: FAILURE in 5 hr 51 min: https://lpci.wedontsleep.org/job/db-devel/678/
[12:01] <LPCIBot> Project parallel-test build #82: STILL FAILING in 37 min: https://lpci.wedontsleep.org/job/parallel-test/82/
[12:01] <LPCIBot> Launchpad Patch Queue Manager: [r=jml][no-qa] Remove syncUpdate.
[12:07] <poolie> benji, lifeless, has anyone actually got a login yet?
[12:07] <lifeless> I haven't; I can't decide if I should, or should not :)
[12:07] <benji> heh
[12:12] <nigelb> poolie: maco did get a login for it if you're looking for feedback
[12:12] <nigelb> (it being mergebox)
[12:25] <lifeless> bigjools: dsds are shaping up really quite nice
[12:25] <bigjools> lifeless: hellyeah!
[12:25] <lifeless> bigjools: I hit a small usability thing today, not sure if its a bug or not.
[12:26] <lifeless> bigjools: I wanted to answer, for a friend 'whats different between debian and ubuntu for virt-manager and libvirt-bin'
[12:26] <bigjools> that is not enough info to properly ascertain an answer
[12:27] <lifeless> bigjools: localpackagediffs doesn't seem to have a unfiltered view
[12:27] <bigjools> it's always series-dependent
[12:27] <bigjools> lifeless: !
[12:27] <bigjools> yes it does
[12:27] <lifeless> like there is unignored, ignored, ignored-and-newer, and resolved
[12:27] <bigjools> oh that
[12:27] <bigjools> there's a bug about tha
[12:27] <bigjools> t
[12:27] <lifeless> kk
[12:27] <lifeless> I shall not file one then
[12:28] <lifeless> did I mention usb2 is painfully slow ?
[12:28] <bigjools> lifeless: thx for feedback though
[12:28] <lifeless> de nada
[12:29] <lifeless> my friend uses Debian and then whinges that stuff doesn't Just Work :)
[12:29] <StevenK> lifeless: USB 2 sucks, use something better.
[12:29] <bigjools> there's an answer to that
[12:29] <lifeless> StevenK: would-if-I-could
[12:29] <StevenK> lifeless: There is this thing, called eSATA?
[12:30] <lifeless> StevenK: external disk only having usb2
[12:30] <lifeless> StevenK: I just backed up everything from my old desktop onto it, and it got 30MB/s sustained... restoring at the same rate :(
[12:32] <StevenK> lifeless: The last time I copied stuff over USB 2, I copied 800GiB at an average of 3MB/s, and it took 4 days.
[12:34] <lifeless> StevenK: -ouch-
[12:34] <lifeless> StevenK: I'm only doing 400GB and still its painfule
[12:36] <huwshimi> StevenK: https://launchpad.net/launchpad/+bugs?field.tag=easy+ui&field.tags_combinator=ALL
[14:26] <huwshimi> StevenK: I forgot to mention, if you fix a bug then tag it with "dublin" so we can keep track of the bugs fixed here
[14:34] <huwshimi> benji: I have updated this branch, just wanted to check the fix looks ok: https://code.launchpad.net/~huwshimi/launchpad/table-headings-728187/+merge/66008
[14:44] <benji> huwshimi: I made positive sounds on the MP.
[14:44] <huwshimi> benji: Thank you!
[15:00] <Riddell_> StevenK: are you able to point me in the direction of writing tests for my 797688-packaging-branches-label branch at some point?
[15:56] <StevenK> benji: https://code.launchpad.net/~stevenk/launchpad/archive-picker-value/+merge/66318
[15:56] <jtv> bigjools, StevenK, wgrant: any objections to a df app restart?
[15:56] <StevenK> jtv: No, doit.
[15:56] <wgrant> jtv: None.
[15:56] <jtv> StevenK: who are you calling a doit?
[15:57] <jtv> …or whommm?
[15:57] <StevenK> jtv: You, duh.
[15:57] <jtv> oh, I see.
[15:58] <benji> StevenK: done
[16:02] <danilos> jtv, hey, I've got a question about the expander widget: how do I make it start out expanded?
[16:03] <jtv> danilos: disable JS.  :)
[16:03] <danilos> jtv, ok, so that's a feature we are missing: if "expanded" flag is on it on load, we should probably not fold it
[16:03] <jtv> Sure.
[16:03] <danilos> jtv, it's a case I hit on a page
[16:03] <jtv> I mentioned this yesterday as "nice for later"; I guess "later" came early
[16:03] <danilos> jtv, ok, I'll assume that works and just set the "expanded" class on the content node
[16:04] <jtv> BTW where is that flag exactly?  Is it a CSS class, a config arg..?
[16:04] <danilos> jtv, yeah, I was not sure if it was implemented or not, and it's needed to be able to replace the existing collapsible stuff
[16:04] <jtv> Ah
[16:04] <danilos> jtv, a CSS class state_marker.expanded
[16:04] <jtv> OK
[16:07] <Riddell> StevenK: https://code.launchpad.net/~jr/launchpad/797688-packaging-branches-label/+merge/66146
[16:09] <bigjools> jtv: nup
[16:10] <jtv> ?
[16:13] <Riddell> StevenK: voila
[16:13] <Riddell> hmm, wait
[16:31] <StevenK> benji: https://code.launchpad.net/~mbp/lazr.restfulclient/789369-getattr/+merge/62743
[16:41] <matsubara> anyone available to review a branch that attempts to fix bug 404279? https://code.launchpad.net/~matsubara/launchpad/404279-private-ppa-link/+merge/66335
[16:41] <_mup_> Bug #404279: apt urls on private ppa pages are incorrect (missing credentials) <bugjam2010> <easy> <lp-soyuz> <p3a> <ppa> <ui> <Launchpad itself:In Progress by matsubara> < https://launchpad.net/bugs/404279 >
[17:03] <poolie> i will try
[17:10] <bigjools> stub: addAfterCommitHook doesn't work....
[17:10] <bigjools> he no callee backee
[17:10] <stub> You said it worked!
[17:10] <bigjools> I LIED
[17:11] <stub> commit is being called?
[17:11] <bigjools> yes, we just stepped in pdb
[17:12] <stub> bigjools: So we know the concept is sound, or else PostgreSQL connections would never be committed.
[17:13] <stub> bigjools: Oh.... aftercommithook... not sure if they are used anywhere.
[17:13] <bigjools> indeed
[17:13] <stub> Maybe just a standard commit hook?
[17:13] <bigjools> define "standard" ?
[17:13] <stub> We can worry about ordering of rabbit or pg first later
[17:13] <bigjools> the other one I can see in the doc is  beforeCommitHook()
[17:14] <bigjools> stub: maybe we need registerSynch
[17:15] <stub> Now I can't find the documentation...
[17:15] <bigjools> stub: http://readthedocs.org/docs/zodb/en/latest/transactions.html
[17:15] <wgrant> It's not a synchronizer.
[17:15] <stub> You can register a class with the prepare, commit, rollback hooks like a pg database connection does
[17:15] <wgrant> It's not a beforeCommitHook.
[17:15] <wgrant> It's also not an IDataManager
[17:16] <bigjools> stub: how do you register that?
[17:17]  * stub wonders if our transaction package is out of date with those docs
[17:17] <bigjools> and buggy
[17:17] <stub> Writing it as a full blown datamanager should work
[17:17] <stub> And not too traumatic since most of the methods will be noops
[17:17] <bigjools> ok
[17:18] <bigjools> stub: got an example we can see?
[17:18] <bigjools> preferably in our code :)
[17:19] <stub> bigjools: Those docs have one. Otherwise ZStorm has one. Nothing in the lp tree though.
[17:20] <stub> The one in the docs will be simpler, and that api has been stable for over 10 years (apart from doom which we added)
[17:23] <stub> Hmm... but I wonder if something else is going on. Given the aftercommit api exists, I would sort of expect it to do what it says on the tin
[17:25] <stub> bigjools: Your hook has the right signature?
[17:25] <stub> foo(success, args, kwargs)
[17:25] <stub> kws
[17:26] <stub> finished here - popping down
[17:44] <LPCIBot> Yippie, build fixed!
[17:44] <LPCIBot> Project db-devel build #679: FIXED in 5 hr 52 min: https://lpci.wedontsleep.org/job/db-devel/679/