[00:00] <wgrant> bigjools: "requested to review"
[00:00] <wgrant> It's the reviewer
[00:00] <wgrant> Not a subscriber
[00:00] <bigjools> so that overrides sibscription settings saying not to email?
[00:00] <bigjools> sigh
[00:00] <bigjools> ok how do I stop this?
[00:00] <lifeless> it doesn't override, its direct notification
[00:00] <lifeless> remove maas-lander from maas-maintainers
[00:00] <wgrant> Set a team email address
[00:00] <wgrant> Or remove maas-lander from maas-maintainers, yeah
[00:01] <lifeless> put maas-lander and maas-maintainers both in ~canonical-launchpad-branches or a similar branch-only-access team
[00:01] <bigjools> then it won't be able to land stuff
[00:01] <mwhudson> lifeless: that's basically a way for evil js to get at http-only cookies isn't it?
[00:01] <bigjools> man this stuff is over complicated
[00:01] <lifeless> thats *why* we have that structure in LP, and why I encouraged you to use the same teams, or the same structure, for MAAS :)
[00:01] <bigjools> lifeless: I understand - or rather I don't understand why it needs to be so complex :(
[00:01] <lifeless> mwhudson: http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29
[00:02] <mwhudson> lifeless: "It relies on the attacker being able to observe the size of the ciphertext sent by the browser while at the same time inducing the browser to make multiple carefully crafted web connections to the target site."
[00:02] <mwhudson> lifeless: if you can do that, you can just carefully craft the results to do evil directly, surely?
[00:02] <lifeless> mwhudson: yes, but the demonstration is terrifying
[00:03] <mwhudson> it's a super cool hack
[00:03] <lifeless> mwhudson: no, you can't
[00:03] <wgrant> mwhudson: No
[00:03] <wgrant> mwhudson: By crafting part of a body I can reveal the headers
[00:03] <wgrant> eg. if I control a string embedded deep in JSON somewhere
[00:04] <bigjools> !!!!!! I can't set a contact address that is the same as another team's
[00:04] <lifeless> bigjools: I wouldn't go the contact address route
[00:04] <lifeless> bigjools: it gets super messy.
[00:04] <wgrant> ...
[00:05] <bigjools> I was going to redirect email to launchpad-reviewers
[00:05] <wgrant> This is already super-messy, and the complex team structure doesn't make it any less messy
[00:05] <bigjools> exactly wgrant
[00:05] <wgrant> MP notifications are fundamentally broken
[00:05] <wgrant> It's always going to be messy until they're fixed
[00:06] <bigjools> I don't understand the arbitrary refusal to set the contact address to be the same as another team
[00:06] <bigjools> that's bizarre
[00:06] <wgrant> It's not arbitrary
[00:06] <wgrant> It's less than ideal
[00:06] <wgrant> But it's certainly not arbitrary
[00:06] <bigjools> the error on screen should say why instead of appearing to be arbitrary
[00:06] <wgrant> Launchpad doesn't just use it as a contact address
[00:06] <wgrant> It's also used to look up the team
[00:06] <wgrant> Mostly by Soyuz
[00:06] <bigjools> headdesk
[00:07]  * bigjools sets contact address to<EMAIL_ADDRESS>[00:07] <wgrant> Good luck confirming that :)
[00:08] <bigjools> bollocks, it ignored it!
[00:08] <bigjools> this is fucking infuriating :/
[00:08] <lifeless> wgrant: I agree that things could be better, but given the *current code base* I think the simplest way to manage it is leaf teams for things that do stuff, and organisational teams put into those.
[00:08] <lifeless> wgrant: arguing that its broken just aknowledges that it is.
[00:08] <bigjools> is this recommended structure documented anywhere on the lp wiki?
[00:09] <lifeless> wgrant: the other reason to do it the same way as LP is that it would be the same way as LP
[00:09] <lifeless> bigjools: https://dev.launchpad.net/CreatingNewProjects
[00:09] <bigjools> thanks
[00:09] <wgrant> lifeless: Sure, but that requires renaming branches everywhere
[00:09] <wgrant> lifeless: So it's far less destructive to set a contact address
[00:09] <lifeless> wgrant: ah, that is a cost to moving, yes.
[00:09] <lifeless> which will hurt.
[00:10] <bigjools> lifeless: not sure that page helps
[00:10] <lifeless> bigjools: I don't think we captured the how-we-got-there anywhere other than the list archives :( - sorry!
[00:10] <lifeless> I have to run, shopping trip to do
[00:10] <bigjools> lifeless: :(
[00:11] <lifeless> back soon, good luck solving your headache.
[00:11] <lifeless> my 2c before I go
[00:11] <lifeless>  - make a new team -reviewers and copy the direct member list from -maintainers to -reviewers
[00:11] <lifeless> make it the reviewer
[00:12] <lifeless> make it owned by -maintainers
[00:12] <lifeless> and refactor to remove duplication post-release.
[00:17]  * bigjools made launchpad-reviewers the reviewer
[00:18] <wgrant> My inbox thanks you
[00:19] <bigjools> lp-reviewers was a member of the old team anyway
[00:19] <wgrant> Yeah
[00:19] <wgrant> But now I'll get less mail :)
[00:19] <bigjools> that was the idea :)
[00:22] <bigjools> also, when I change the status of an MP to approved it'd be really nice if it either warned about new versions not in the page or just approved them anyway
[00:22] <bigjools> :/
[00:45] <lifeless> zomg its a statik
[00:53] <wgrant> 2012-09-25 22:55:56 INFO    Outage complete. 0:00:01.818455
[00:53] <wgrant> getting there
[00:53] <wgrant> (from the latest staging update)
[00:54] <StevenK> What, too long?
[00:55] <wgrant> No reason for it to take more than a couple of hundred milliseconds
[00:56] <lifeless> StevenK: yeah
[00:57] <wgrant> security.py is most of the remaining time, I believe
[00:59] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1056506/+merge/126358
[01:01] <StevenK> wgrant: r=me
[01:01] <wgrant> StevenK: Thanks
[01:02] <StevenK> wgrant: I heartily approve of lines 61-69
[01:02] <wgrant> Yeah...
[01:06] <lifeless> libreoffice starts -fast- on SSD
[01:18] <wgrant> 2012-09-26 01:17:38 INFO    Resetting permissions.
[01:18] <wgrant> Security took 0.780465126038
[01:18] <wgrant> 2012-09-26 01:17:38 INFO    Enabling access to launchpad_dev_master.
[01:18] <wgrant> 2012-09-26 01:17:38 INFO    Outage complete. 0:00:00.888748
[01:18] <wgrant> So security.py is indeed probably most of it
[02:12] <lifeless>       327 /    0  DistroSeries:EntryResource:getBuildRecords
[02:12] <lifeless>       321 /    0  Person:+specworkload
[02:12] <lifeless> :(
[02:22] <StevenK> Why do we get a PQM success mail at 11:59 and then a failure at 12:04?
[02:25] <wgrant> StevenK: There are lots of mail delays
[02:25] <wgrant> StevenK: So buildbot-poll sends the email
[02:25] <wgrant> It gets stuck in a queue
[02:26] <wgrant> 5/10 minutes later, buildbot-poll sees there's still stuff to merge
[02:26] <wgrant> Sends the email
[02:26] <wgrant> Mail queue unclogs, PQM processes both
[02:26] <StevenK> I look forward to when we can kill buildbot-poll
[02:42]  * StevenK stabs lxc
[03:35] <StevenK> wgrant: LXC is impenetrable.
[03:35] <wgrant> StevenK: Howso?
[03:36] <StevenK> I don't understand it at all!
[03:36] <wgrant> I know parts of it all too intimately.
[03:36] <wgrant> What is it doing to you?
[03:36] <StevenK> I destroyed the ec2 instance in disgust before lunch, but the lxc-setup-build script in examples was hanging
[03:37] <wgrant> StevenK: Did you have a base container set up properly?
[03:37] <wgrant> And where was it hanging?
[03:38] <StevenK> lxc-wait -n or so, I think
[03:38] <StevenK> And base container?
[03:38] <StevenK> See previous statement about impenetrability.
[03:38] <wgrant> lp-setup-lxc-build relies on there being a base container already
[03:38] <wgrant> It builds LP inside a container
[03:39] <wgrant> You can use lpsetup to create this container
[03:41] <lifeless> I wonder if we need more 'this is how its all put together' docs for this
[03:44] <wgrant> Yeah
[03:44] <wgrant> Particularly since the in-DC setup is different
[03:44] <wgrant> I suspect we'll be able to pull together docs from me watching StevenK trip over everything :)
[03:45] <StevenK> Oh. Yay?
[03:46] <wgrant> StevenK: So, do you understand the high-level fundamentals of how parallel testing is implemented for LP today?
[03:46] <wgrant> I suspect few outside lifeless, I, Yellow, and some ops, do
[03:47] <wgrant> But I'm not sure how much you've picked up on
[03:47] <wgrant> As it's all a bit complicated
[03:47] <StevenK> wgrant: We create 20 containers run a portion of the tests in them, and testr interleaves it all together into a useful subunit stream
[03:47] <wgrant> StevenK: Right
[03:48] <wgrant> Now, the 20 containers aren't all created from scratch each time
[03:48] <wgrant> They're ephemeral (created by the aptly named lxc-start-ephemeral) as clones of a base container
[03:49] <wgrant> This base container has LP code+deps+DB etc in it.
[03:49] <wgrant> And it's persistent
[03:49] <wgrant> lxc-start-ephemeral uses aufs or overlayfs to create effectively COW snapshots of the base container's tree
[03:49] <StevenK> Right
[03:49] <wgrant> Then bring up a new throwaway container on that
[03:50] <wgrant> You can see the buildbot config in lp:~launchpad/lpbuildbot/public
[03:50] <wgrant> With a testr.conf that calls IIRC lp-setup-lxc-test to run bin/test in an ephemeral container
[03:51] <StevenK> Yes, it calls /usr/local/bin/lp-setup-lxc-test
[03:51] <wgrant> testr just calls the command there to run the tests, so testr doesn't know about LXC at all
[03:51] <wgrant> As far as it's concerned it's just running 20 parallel testrunners locally
[03:51] <StevenK> I was guessing I needed lp-setup-lxc-build first, but like I said, that wasn't filled with happiness
[03:52] <wgrant> Right, lp-setup-lxc-build is run as one of the earlier phases of each full testsuite run
[03:52] <wgrant> It basically just runs 'make build schema'
[03:52] <wgrant> So that's done in the base container, rather than separately in each cloned one
[03:52] <wgrant> But it relies on there being a container already
[03:53] <wgrant> lpsetup init-lxc can probably create it for you
[03:53] <wgrant> In the DC we do it manually
[03:54] <StevenK> Right
[03:54] <wgrant> There's nothing really special about the container created by lpsetup
[03:55] <wgrant> You can get something roughly equivalent by running rocketfuel-setup in a normal container from lxc-create
[03:55] <StevenK> wgrant: I'll bring up an ec2 instance in a bit, working on failing tests from my storm branch.
[03:55] <wgrant> There were failures? :(
[03:56] <wgrant> Query issues, or just things expecting SQLObjectResultSets?
[03:56] <StevenK> Yeah, there was a callsite of handleOptional... hiding in registry/sourcepackage.py
[03:56] <wgrant> Oh
[03:56] <wgrant> Sinister
[03:56] <wgrant> Oh right
[03:56] <wgrant> That one
[03:56] <StevenK> Yeah
[03:56] <StevenK> Which I'd like to destroy
[03:56] <wgrant> I tried once upon a time to make the build API sensible
[03:56] <wgrant> But didn't quite get all the way
[03:57] <StevenK> wgrant: Can I kill _get_ubuntu in that class?
[03:58] <wgrant> StevenK: That comment is prehistoric and no longer correct
[03:58] <StevenK> So I can kill it?
[03:58] <wgrant> You should be able to use an inline ILaunchpadCelebrities lookup instead
[03:58] <wgrant> Yeah
[03:58] <StevenK> I was going to, yeah
[03:58] <wgrant> However
[03:58] <wgrant> Hmm
[03:59] <wgrant> Check the history on .packaging
[03:59] <wgrant> I think the Ubuntu specialcase can probably be removed
[03:59] <wgrant> It's the only callsite of priorReleasedSeries
[03:59] <wgrant> And seems pretty pointless
[04:00] <wgrant> Because Ubuntu should have previous_series set properly everywhere
[04:02] <StevenK> Yeah
[04:03] <wgrant> Even in sampledata
[04:03] <wgrant> So I'd try removing that specialcase and all the priorReleasedSeries definitions and seeing if the test suite complains
[04:03] <StevenK> That gets this branch to -60
[04:04] <wgrant> You removed it from DistroSeriesSet and the interfaces too?
[04:04] <StevenK> Nope
[04:04] <StevenK> Hold on, removed what?
[04:04] <wgrant> priorReleasedSeries
[04:05] <wgrant> Its sole callsite is the Ubuntu specialcase in SourcePackage.packaging
[04:05] <wgrant> And I can't see any value in that special case.
[04:05] <wgrant> You might be able to find something
[04:05] <wgrant> But I really can't
[04:06] <StevenK> Right, it's terrible
[04:07] <wgrant> Since Ubuntu releases are serial, the first priorReleasedSeries is always going to be previous_series
[04:07] <wgrant> Except when we're on a non-released non-development series
[04:07] <wgrant> Like q-series or r-series
[04:07] <wgrant> Their first priorReleasedSeries is the current release
[04:07] <wgrant> precise
[04:07] <wgrant> not quantal
[04:08] <wgrant> But that provides no value, since with the special case removed it will fall back to quantal which will fall back to precise
[04:08] <wgrant> So yeah
[04:08] <wgrant> Delete the special case
[04:08] <wgrant> Then probably lp-land and see if buildbot complains
[04:08] <wgrant> It probably won't, and if it does then the fix is easy and meh.
[04:08] <StevenK> % bzr damage
[04:08] <StevenK> Using submit branch /home/steven/launchpad/lp-branches/devel
[04:08] <StevenK> Healing: 134 lines of code
[04:08] <wgrant> :)
[04:08] <wgrant> You got both priorReleasedSeries methods and their respective interfaces?
[04:09] <StevenK> And the *enormous* test
[04:10] <StevenK> % bzr grep priorReleasedSeries | wc -l
[04:10] <StevenK> 0
[04:10] <wgrant> :)
[04:10] <wgrant> https://code.launchpad.net/~julian-edwards/launchpad/set-previous-series-bug-805913/+merge/66942
[04:10] <wgrant> is very relevant
[04:11] <bigjools> what
[04:12] <wgrant> StevenK: The addendum there doesn't make much sense to me
[04:12] <wgrant> If there are many unreleased series, then it will just recurse back
[04:13] <StevenK> Indeed
[04:13] <wgrant> It's not necessary to jump straight to the last released one, AFAICT
[04:13] <StevenK> wgrant: Do you want to eyeball a diff before I commit, push and lp-land?
[04:13] <wgrant> StevenK: If you push I'll check the MP
[04:14] <wgrant> bigjools: I'm guessing that's all a blur and you don't remember the context around that MP any more?
[04:15] <StevenK> wgrant: Pushed
[04:15] <bigjools> not looked, otp
[04:17] <StevenK> bigjools: Not still dealing with broker from hell?
[04:17] <bigjools> no thankfully
[04:18] <wgrant> StevenK: The amount of red in the incremental diff pleases my eyes.
[04:21] <wgrant> StevenK: Can you run -t packaging or so?
[04:21] <wgrant> Just in case there's something obvious
[04:28] <StevenK> wgrant: Total: 109 tests, 0 failures, 0 errors in 6 minutes 27.422 seconds.
[04:28] <StevenK> Total: 109 tests, 0 failures, 0 errors in 6 minutes 27.422 seconds.
[04:28] <StevenK> BLEH, this double paste is getting annoying
[04:32] <wgrant> StevenK: Sounds good
[04:32] <StevenK> Let me lp-land it
[04:35] <wgrant> StevenK: Indeed
[04:38] <wallyworld> cody-somerville: you around?
[04:42]  * StevenK stabs init-lxc for wanting lots of information
[04:43] <wgrant> wallyworld: lazr.restful already has infrastructure for detecting canonical_url changds
[04:43] <wgrant> Though I'm not sure why it's not working here
[04:43] <wallyworld> this is lazr.restfulclient
[04:43] <wallyworld> and the code path does not detect it
[04:44] <wgrant> wallyworld: Sure, but lazr.restful detects a change and sends a 301 with Location
[04:44] <wallyworld> clearly not :-)
[04:44] <StevenK> Blink. It debootstraps?
[04:44] <wallyworld> this is a fairly old bug too
[04:44] <wgrant> Well, yeah, it doesn't work in this case
[04:44] <wgrant> But I'd probably investigate why it doesn't work
[04:44] <StevenK> I'm going to be unhappy if this requires an LP account
[04:45] <wgrant> Rather than adding that somewhat terrible model hack
[04:45] <wgrant> StevenK: Why wouldn't it debootstrap?
[04:45] <wgrant> It needs to create a fresh installation for the container
[04:45] <StevenK> wgrant: Wasn't expecting it is all
[04:45] <wgrant> It should be OK with grabbing the branches from LP anonymously, though
[04:45] <StevenK> You'd think
[04:46] <StevenK> I've fed it nonense, so we'll see
[04:47] <wgrant> wallyworld: See lazr.restful._resource.EntryManipulatingResource.applyChanges() for the code which does it on attribute changes
[04:47] <wgrant> But I guess not on method calls
[04:47] <lifeless> we could run an image rather than debootstrap
[04:47] <wallyworld> ok, will look. i didn't realise lazr.restful detected url changes
[04:47] <lifeless> but LXC isn't [currently] run that way
[04:47] <StevenK> Rargh
[04:48] <StevenK> lpsetup needs a bug
[04:48] <StevenK> It pulls from archive no matter what, it should be configurable
[04:48] <wgrant> wallyworld: I'm not quite sure where method calls are done, but I know it automatically calls ObjectModifiedEvent, so there must be something there
[04:48] <wgrant> StevenK: Ah yeah
[04:49] <wgrant> StevenK: I manually ran lxc-create with MIRROR=whatever beforehand
[04:49] <lifeless> wgrant: have you had time to look at the ghosts?
[04:49] <StevenK> Sadly, it's going faster than the ec2 mirror
[04:49] <wgrant> lxc-create stores a cache keyed on (distroseries, archtag)
[04:49] <wallyworld> wgrant: by "it", you mean lazr.restful i assume
[04:49] <StevenK> So I can't complain much
[04:49] <wgrant> wallyworld: Right, sorry
[04:49] <wallyworld> ok
[04:49] <wgrant> lifeless: Not yet, as it doesn't seem overly urgent. If you want me to I'll get onto it nowish, though
[04:50] <wgrant> I've been fixing bugs to make bigjools shut up :P
[04:50] <StevenK> That fix should be deployed soon
[04:50] <wgrant> Indeed :)
[04:51] <StevenK> wgrant: Right, so init-lxc just finished
[04:51] <lifeless> wgrant: I'd like to know its good this week
[04:51] <wgrant> StevenK: Did it branch LP stuff into it and stuff?
[04:51] <lifeless> wgrant: as config changes when they are needed, are generally needed now
[04:51] <wgrant> lifeless: Yeah, true
[04:51] <wgrant> And we have no ops next week
[04:51] <StevenK> wgrant: I don't think so
[04:51] <StevenK> wgrant: How can I check?
[04:51] <lifeless> wgrant: exactly
[04:52] <wgrant> StevenK: ls ~
[04:52] <lifeless> wgrant: does the lp-setup-lxc stuff bind-mount ~?
[04:52] <lifeless> or does it do a fresh copy of everything ?
[04:52] <StevenK> root@ip-10-78-117-158:~# ls -lh ~
[04:52] <StevenK> total 0
[04:52] <wgrant> lifeless: it bind mounts ~
[04:52] <wgrant> StevenK: Ah right
[04:53] <lifeless> thats root though :P
[04:53] <wgrant>     init-lxc            Create an LXC container suitable for later installing
[04:53] <wgrant>                         a Launchpad development environment.
[04:53] <wgrant>     init-repo           Get the Launchpad code and dependent source code.
[04:53] <wgrant>     install-lxc         Completely sets up an LXC environment with Launchpad
[04:53] <wgrant>                         using the sandbox development model.
[04:53] <StevenK> Oh, bleh
[04:53] <lifeless> StevenK: tell me you ran that as root ?
[04:53] <StevenK> lifeless: Which as root?
[04:53] <lifeless> StevenK: is this on your machine ?
[04:53] <wgrant> From install-lxc:
[04:53] <wgrant>     This is basically the same as running `init-lxc` and then, inside the \
[04:53] <wgrant>     newly created container, `lp-setup init-repo`, `lp-setup update`, and
[04:53] <wgrant>     `make install`.
[04:54] <StevenK> lifeless: Note the hostname
[04:54] <lifeless> StevenK: doesn't tell me anything
[04:54] <StevenK> It's an m2.xlarge ec2 instance
[04:54] <lifeless> StevenK: thanks
[04:54] <StevenK> m2.2xlarge, rather
[04:54] <StevenK> 34GiB of RAM
[04:54] <wgrant> StevenK: So I'd start the container, SSH in, and run lp-setup init-repo, lp-setup update, make install
[04:55] <StevenK> lxc-start lptests ?
[04:55] <wgrant> sudo lxc-start -n lptests -d
[04:55] <wgrant> Without -d it'll start in the foreground and give you local console
[04:55] <wgrant> Which is usually undesirable
[04:56] <wgrant> You can then use lp-lxc-ip (or something close to that) to determine the IP address to give to ssh
[04:56] <StevenK> I thought it was ubuntu/ubuntu
[04:56] <wgrant> It should be the username and password of whatever account you ran it as, usually
[04:56] <wgrant> But otherwise ubuntu/ubuntu
[04:56] <wgrant> Or root/
[04:57] <StevenK> root/ doesn't work either
[04:57] <wgrant> It's possible that running it as a passwordless root account has confused it
[04:57] <wgrant> Check /var/lib/lxc/lptests/rootfs/etc/shadow
[04:59] <StevenK> Disabled root, it has an jenkins account
[04:59] <StevenK> But the password isn't jenkins or test or ubuntu or test
[04:59] <wgrant> Ah, if you ran it as jenkins then it'll have copied your host's jenkins password
[04:59] <StevenK> Ahh
[04:59] <StevenK> That I know
[05:00] <wgrant> I thought you ran it as root, given the PS1 earlier
[05:00] <StevenK> It insisted I run it with -u
[05:00] <wgrant> Ah
[05:00] <wgrant> Right
[05:00] <StevenK> lp-setup init-repo: error: No bzr launchpad-login set.
[05:00] <StevenK> Bleh
[05:01] <wgrant> vim is your friend
[05:01] <wgrant> I suspect
[05:01]  * StevenK adds --use-http
[05:01] <wgrant> Or that
[05:03] <StevenK> Hm, the amount of progress printed is staggering
[05:04] <wgrant> In which direction?
[05:04] <StevenK> Do you want to proceed? [y/N] y
[05:04] <StevenK>
[05:04] <wgrant> Heh
[05:05] <StevenK> Right, it is doing something, it just isn't telling me
[05:08]  * wgrant watches 2500 gpg prompts fly past
[05:09] <StevenK> Hm?
[05:09] <wgrant> I should probably have disabled signing before running mkghosts
[05:10] <StevenK> Heh
[05:10] <StevenK> 20 failures
[05:10] <StevenK> 6 errors
[05:10] <StevenK> So, I love
[05:10] <StevenK> lose, even
[05:11] <lifeless> wgrant: wheee :P
[05:11] <wgrant> StevenK: Hm, what
[05:11] <wgrant> You lost
[05:11] <wgrant> Terribly
[05:11] <wgrant> But how
[05:11] <wgrant> Those errors don't make much sense
[05:11] <wgrant> It looks like the DSP is ending up None
[05:12] <StevenK> BrokenImplementation: An object has failed to implement interface <InterfaceClass lp.answers.interfaces.questiontarget.IQuestionTarget>
[05:12] <wgrant> Ah, no
[05:12] <wgrant> It's just answer_contacts that's broken, it seems
[05:13] <wgrant> By "The answer_contacts attribute was not provided" it means "AttributeError: 'NoneType' object has no attribute 'using'"
[05:13] <StevenK> How did I manage to screw that up?
[05:13] <wgrant> Oh heh
[05:13] <wgrant>      @property
[05:13] <wgrant> -    def _store(self):
[05:13] <wgrant> -        return Store.of(self.sourcepackagename)
[05:13] <wgrant> -
[05:13] <wgrant> That would do it
[05:13] <wgrant> in sourcepackage.py
[05:14] <StevenK> Oh, I thought that was unused!
[05:14] <StevenK> I even bzr grepped for it
[05:14] <wgrant> QuestionTargetMixin uses it
[05:15] <wgrant> Anyway, this is why we have 35 minute buildbot :)
[05:15] <StevenK> Heh
[05:15] <StevenK> Putting together a testfix
[05:15] <wgrant> It looks like the only failure, but you would do well to wait until this run finishes and then run all the failures
[05:15] <StevenK> It's going to require a branch anyway, but yeah
[05:17] <StevenK> It just finished
[05:17]  * StevenK grabs the stream
[05:17] <wgrant> http://lpbuildbot.canonical.com/builders/lucid_lp_lxc/builds/39/steps/shell_9/logs/subunit/text should be what you want, yeah
[05:18] <StevenK> Indeed
[05:18] <StevenK> I was already wgetting when I said I was grabbing it
[05:18] <StevenK> And I'm now waiting on testr run --failing
[05:18] <StevenK> (and bzr on said ec2 ...)
[05:19] <StevenK> jenkins@lptests:~$ du -sh launchpad/lp-branches/.bzr
[05:19] <StevenK> 229M	launchpad/lp-branches/.bzr
[05:19] <wgrant> :)
[05:20] <StevenK> Ran 84 (-22077) tests in 131.750s (-1768.113s)
[05:20] <StevenK> PASSED (id=1, skips=6)
[05:21] <wgrant> Excellent
[05:21] <StevenK> OMG, it finished
[05:21] <wgrant> Your ec2 instance?
[05:22] <StevenK> Yeah
[05:22] <StevenK> lp-setup update depends on CWD? :-(
[05:22] <wgrant> Yes
[05:22] <wgrant> as do lp-setup-lxc-test and lp-setup-lxc-build
[05:22] <wgrant> It makes a fair bit of sense
[05:23] <StevenK> jenkins@lptests:~/launchpad/lp-branches/devel$ lp-setup update
[05:23] <StevenK> lp-setup update: error: the target dir /home/jenkins/launchpad/lp-branches/devel is not a valid Launchpad tree.
[05:24] <StevenK> lp-setup update: error: the target dir /home/jenkins/launchpad/lp-branches/devel is not a valid Launchpad tree.
[05:24] <wgrant> Not seen that before
[05:24] <wgrant> Luckily the code is quite sensible
[05:24] <StevenK> Oh, it's in sandbox, for ... some reason
[05:25] <StevenK> Testfix landed
[05:27] <wgrant> Thanks
[05:27] <wgrant> StevenK: Right, it uses lightweight checkouts
[05:27] <wgrant> devel is a treeless branch
[05:27] <wgrant> sandbox is a lightweight checkout
[05:27] <StevenK> And devel is empty
[05:27] <wgrant> It has a .bzr
[05:27] <wgrant> But that's it
[05:36] <lifeless> wgrant: StevenK: more low hanging fruit: https://bugs.launchpad.net/loggerhead/+bug/869309
[05:36] <_mup_> Bug #869309: If folders in repository have unicode names, sometimes I get KeyError <navigation> <oops> <trivial> <unicode> <loggerhead:Triaged> < https://launchpad.net/bugs/869309 >
[05:36] <lifeless> brought to my attendion by the new user that just assigned it to themselves ><
[05:37] <wgrant> lifeless: But there's no low-hanging fruit :)
[05:37] <lifeless> wgrant: it has a patch attached.
[05:37] <lifeless> wgrant: doesn't get much lower :)
[05:37] <wgrant> Indeed
[05:42] <StevenK> wgrant: Right, that's all done on my ec2 slave
[05:45] <wallyworld> is it just me or does anyone else's screen dimming fail to turn the screen back when the mouse is moved? the pointer shows up but the screen stays black :-(
[05:47] <lifeless> wallyworld: that could be a dropped vsync for unity
[05:47] <lifeless> wallyworld: it looks like a dimming problem, but it isn't
[05:48] <wallyworld> it doesn't happen if i turn off "screen dimming after 10 minutes"
[05:48] <wallyworld> so i just got back from making a coffee and boom :-(
[05:48] <wallyworld> cause i forgot to turn it off again
[05:49] <lifeless> chat to RAOF
[05:49] <lifeless> in #ubuntu-dekstop
[05:49] <lifeless> desktop
[05:49] <lifeless> once they finish figuring out where to put the privacy setting
[05:50] <wallyworld> ok, i'll search bugs first
[05:51] <StevenK> wgrant: So, next step?
[05:53] <wgrant> StevenK: Do stuff
[05:53] <wgrant> Um
[05:53] <wgrant> StevenK: In sandbox on the host, run lp-setup-lxc-build
[05:53] <wgrant> See if it works
[05:57]  * StevenK stabs it for prompting for a sudo password every 2 seconds
[06:04] <StevenK> wgrant: In a word, no
[06:04] <wgrant> Heh
[06:04] <wgrant> buildbot loves you, though
[06:05] <wgrant> StevenK: What broke?
[06:05] <wgrant> "Everything" is an acceptable answer.
[06:06] <StevenK> The script
[06:07] <StevenK> wgrant: http://pastebin.ubuntu.com/1227964/
[06:07] <wgrant> This command has to be run as root
[06:07] <wgrant> sudo it?
[06:07] <wgrant> Ah
[06:07] <wgrant> You did
[06:08] <wgrant> StevenK: Why ~/lp-setup-lxc-build rather than the one installed in PATH?
[06:08] <wgrant> Did you hack it
[06:08] <wgrant> ?
[06:08] <StevenK> There is none in PATH
[06:08] <wgrant> lp-setup should have come with one
[06:08] <wgrant> I thought
[06:09] <StevenK> It's in /usr/share/pyshared/lpsetup/templates/lp-setup-lxc-build
[06:09] <wgrant> Ah
[06:09] <wgrant> Right
[06:09] <StevenK> And I got sick of that long path so I copied it and +x'd it
[06:09] <wgrant> Container {lxc_name} does not exist
[06:09] <wgrant> Sounds like you didn't replace the bits of the template?
[06:09] <StevenK> Oh, I need to sed over it?
[06:10] <wgrant> It takes {lxcip}, {lxc_name} and {ssh_key_path} variables
[06:10] <wgrant> The last is just a local SSH key to use to connect to the containers
[06:11] <StevenK> So I need to fix it, it certainly doesn't use $1 and so on?
[06:11] <wgrant> Right
[06:11] <wgrant> lxcip shouldn't be an arg, but the other two arguably should be
[06:27] <StevenK> wgrant: So the name is lptests or something that will based off it, like current-test-0 or something?
[06:28] <wgrant> StevenK: lptests is the base, the ephemerals will be something like lptests-temp-wefwhjefuwehfuiweghfuiw
[06:29] <StevenK> wgrant: Sorry, I mean what should {lxc_name} be?
[06:29] <wgrant> StevenK: lptests
[06:35] <StevenK> wgrant: So lxc-stop on lptests failed with Operation not permitted, but it seemed to work
[06:36] <lifeless> lp:~lifeless/python-oops-datedir-repo/bug-971255 <- another critical for you, MP coming up
[06:36] <wgrant> StevenK: You need to sudo lxc-* operations, usually
[06:37] <StevenK> Except the whole script is running as root
[06:38] <wgrant> That's a little odd
[06:39] <StevenK> Hm, I think I should done this as an EBS backed instance
[06:40] <StevenK> wgrant: https://qastaging.launchpad.net/builders/palmer/+history?build_text=libc&build_state=all consistenly times out :-(
[06:40] <lifeless> https://code.launchpad.net/~lifeless/python-oops-datedir-repo/bug-971255/+merge/126386
[06:40] <lifeless> wgrant: StevenK: or wallyworld: ^
[06:41] <StevenK> No diff
[06:41] <StevenK> No review
[06:41] <lifeless> StevenK: there is a diff
[06:41] <lifeless> StevenK: thanks to the magic of ajax
[06:42] <StevenK> Looks good
[06:42] <wgrant> StevenK: Indeed, but we're OK as long as the stuff that worked before hasn't regressed.
[06:43] <wgrant> We should probably just drop name filtering from that page eventually
[06:44]  * StevenK destroys this instance
[06:45] <wgrant> StevenK: I'd recommend against using EBS, as that would let you work around setup awkwardness rather than fixing it properly
[06:45] <StevenK> wgrant: I'm trying to avoid the two hour wait lp-setup install-lxc brings
[06:46] <wgrant> AH
[06:46] <wgrant> H
[06:46] <wgrant> Ah
[06:46] <lifeless> aH
[06:59] <lifeless> wgrant: StevenK: wallyworld: https://code.launchpad.net/~lifeless/python-oops-datedir-repo/bug-1003627/+merge/126392 - with this I'll do a release, and we'll have that critical fix-released.
[07:00] <StevenK> Is the prune bug already solved?
[07:00] <lifeless> no
[07:00] <lifeless> the pruning too fast one is
[07:01] <lifeless> this is pruning-the-right-stuff-is-impossible.
[07:01] <lifeless> we have to physically partition the datedir repo for things in different project groups
[07:01] <lifeless> this will fix it
[07:01] <StevenK> Didn't wgrant write a patch for the prune reference bug?
[07:02] <lifeless> he did: 19:00 < lifeless> the pruning too fast one is
[07:02] <lifeless> this is a different prune bug
[07:03] <StevenK> lifeless: r=me
[07:04] <lifeless> thanks
[07:17] <lifeless> wgrant: isn't bug 1050722 FR ?
[07:17] <_mup_> Bug #1050722: prune only searches for OOPS references up to prune_until <Python OOPS Date-dir repository:Fix Released by wgrant> <python-oops-tools:In Progress by wgrant> < https://launchpad.net/bugs/1050722 >
[07:18] <wgrant> lifeless: Ah, indeed
[07:18] <wgrant> Closed, thanks.
[07:33] <lifeless> StevenK: https://code.launchpad.net/~lifeless/python-oops-tools/bug-1003627/+merge/126401 if you would
[07:34] <lifeless> StevenK: I've set a commit message, so if you can toggle the MP to approved (if you do approve) that would rock. Thanks!
[07:34]  * lifeless waves bye-for-a-bit
[07:35] <StevenK> Do not understand why prune is duplicated
[07:48] <adeuring> good morning
[07:56] <lifeless> StevenK: the CLI is the only duplicate
[07:56] <lifeless> StevenK: oops-tools prunes the DB
[07:56] <lifeless> StevenK: datedir-repo prunes disk
[07:57] <lifeless> StevenK: and the API client is in just one place
[07:57] <StevenK> Yes, but you're duplicating logic between them
[07:57] <lifeless> StevenK: the CLI only
[07:59] <wgrant> There is some code that we should dedupe further
[07:59] <wgrant> But it's not completely terrible atm
[07:59] <wgrant> and it can't all be generalised
[08:04] <lifeless> writing a disk-dir implementation of the django orm terrifies me
[08:04] <lifeless> StevenK: thanks!
[08:05] <lifeless> StevenK: wgrant: I'll leave you(purple) to get the prune cronjobs raionalised at a convenient
[08:06] <wgrant> Of course :)
[08:10] <lifeless> wgrant: thanks
[08:12] <mvo> hello, it seems like exports for http://bazaar.launchpad.net/~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal/changes  stopped at Aug 16th for some reason, would it be possible to check if something is stuck/stale (lockfile etc)? it would be nice to get a updated package description export for the ubuntu beta2
[08:12] <czajkowski> wgrant: StevenK wallyworld_ one for you guys to kick or invstigate ?
[08:13]  * wallyworld_ runs away (my packing foo is zero)
[08:13] <wallyworld_> packaging even
[08:14] <dpm> wallyworld_, there's no escape. It's not about packaging, it's about bzr branches ;)
[08:14] <wgrant> wallyworld_: It's actually translations
[08:14] <wgrant> Which none of us have any clue on
[08:14] <wgrant> But let's see
[08:14] <wgrant> That date is a little suspicious
[08:14] <wgrant> I wonder if the import was interrupted by a DC move and left a lock around
[08:14] <wgrant> s/import/export/
[08:14] <wgrant> Since ddtp exports take forever
[08:15] <wallyworld_> ah, is that when the move happened
[08:15] <wgrant> August 18, but yeah
[08:15] <wgrant> Rather close
[08:15] <wgrant> 2012-09-26 05:11:44 ERROR   Failure in ddtp-ubuntu/quantal: LockContention(Could not acquire lock "(local)": )
[08:16]  * mvo has no clue either but hopes it just a "rm export-ddtp-quantal.lock"
[08:16] <wgrant> mvo: bzr break-lock lp:~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal
[08:16] <wgrant> should do it
[08:16] <mvo> \o/
[08:16] <wgrant> Hopefully it'll say there's a lock there from taotie on Aug 18
[08:16] <wgrant> It wasn't killed by the move, but exports were severely broken due to fallout from the move a day after
[08:17] <mvo> wgrant: hm, that did just return, no message no nothing?
[08:17] <wgrant> :(
[08:18] <wgrant> Let's see
[08:23] <wgrant> jam, jelmer, mgz: ^^ any ideas on the above?
[08:28] <czajkowski> wallyworld_: StevenK could one of you please help me out on https://answers.launchpad.net/launchpad/+question/209465
[08:29] <wallyworld_> czajkowski: i think if they use one of the supported bug trackers eg bugzilla etc then lp will import bug data but it will still be available in the external system too
[08:30] <wallyworld_> but i'm not 100% sure what happens the other way
[08:31] <jam> wgrant: http://bazaar.launchpad.net/~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal/.bzr/repository/lock/ and http://bazaar.launchpad.net/~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal/.bzr/branch/lock/
[08:31] <jam> show that no lock is currently held.
[08:31] <czajkowski> wallyworld_: ok thanks :)
[08:31] <wgrant> jam: Exactly
[08:31] <jam> I don't really knowt about the exception you saw.
[08:31] <wgrant> czajkowski: They won't be able to search for or report new bugs on Launchpad, but all data will still be there if they choose to reenable it
[08:31] <jam> It is possible to be a semi-genuine contention, if you are re-opening a branch in a script, and now one side is holding a lock, and the other is trying to do something.
[08:32] <wgrant> jam: It's only been happening on that branch since the move chaos
[08:32] <wgrant> Without code changes
[08:32] <wgrant> So it seems unlikely to be legitimate.
[08:32] <wgrant> I don't see howit can be "(local)" but without a URL
[08:32] <jam> well, we did upgrade bzr in the middle term
[08:34] <wgrant> It worked on Aug 16, we moved to a new server with significant drama on Aug 18, then it hung a bit until Aug 30, and from Aug 31 it's been giving that error
[08:34] <wgrant> Was there a bzr upgrade in those two weeks? Possibly...
[08:42] <cjwatson> tumbleweed: Oh, are you still looking for a db review for your edit-packagesets branch?  https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess has instructions on whom to seek db reviews from
[08:54] <tumbleweed> cjwatson: aha, I never looked there. Thanks
[09:52] <mvo> czajkowski, wgrant: sorry, I was in a meeting now, should I rather file a bugreport about the export issue instead of asking on irc? especially if its not as trivial as I had hoped?
[09:59] <czajkowski> mvo: probablly best that way the maintenance team can look at it
[10:00] <StevenK> Which export issue?
[10:01] <mvo> StevenK: lp:~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal is not getting translation updates anymore since ~1month
[10:09] <mvo> I filed bug https://bugs.launchpad.net/launchpad/+bug/1056752  now
[10:09] <_mup_> Bug #1056752: Translations export not working for lp:~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal <Launchpad itself:New> < https://launchpad.net/bugs/1056752 >
[10:50] <rick_h_> thanks for the qa wgrant
[11:23]  * mpt wonders what "div.first{*margin-right:4%;_margin-right:1.3%}" is supposed to do
[11:24] <mgz> screw with IE users for fun?
[11:25] <mpt> Neither *margin-right nor _margin-right is a valid property, as far as I know
[11:29] <mgz> the star property hack targets IE 7 and less, the underscore hack targets IE 6 and less
[11:29] <rick_h_> wheeee
[11:29] <rick_h_> css hacks ftw
[11:29] <mpt> oh I see
[11:30] <mgz> so, it's deliberatly invalid css to get older buggy browsers that misinterpret it as valid to apply specific rules
[11:30] <mgz> but... that's pretty bad, setting percent margins is likely to just break things anyway
[11:30] <mpt> I was just trying to figure out why bug reports had become unreadable, and it was because my custom Launchpad CSS had stopped working
[11:31] <mgz> and having different values for different browsers then makes working out why something looks funny even more entertaining
[11:31] <rick_h_> ah, well % css rules are generally a good thing as they keep things in scale for different browser sizes
[11:31] <rick_h_> we're not in the land of pixel perfect and such
[11:31] <rick_h_> curious what custom CSS you run with.
[11:32] <mpt> yay, fixed
[11:33] <mpt> rick_h_, http://paste.ubuntu.com/1228291/
[11:33] <rick_h_> mpt: cool
[11:34] <rick_h_> while I like smaller fonts I've often thought a lot of users must find it small
[12:35] <rick_h_> jcsackett: ping when you get a sec
[14:10] <rick_h_> abentley: a review for you if you get a chance please https://code.launchpad.net/~rharding/launchpad/info_type_events/+merge/126317
[14:10] <rick_h_> jcsackett: would appreciate your look as well if you have the bandwidth. ^^
[14:11] <rick_h_> I think this will address the manual usage and we'll see I guess when I follow up and integrate the change into place.
[14:15] <abentley> rick_h_: What happens if an item is private and a feature on the page is in beta?  That should show two banners, but you've made it a singleton, IIUC.
[14:16] <rick_h_> abentley: the beta code is in betabanner.js and has it's own singleton
[14:16] <abentley> rick_h_: cool.
[14:16] <rick_h_> that's just moved code, from the bottom to the top of the file so it's how it currently works
[14:17] <abentley> rick_h_: "@namespace lp.app.banner" reminds me that we haven't reached consensus about whether to separate namespaces from module names.
[14:18] <abentley> rick_h_: But you didn't change that, so that's alright.
[14:18] <rick_h_> abentley: yea, at some point I want to put together some notes/examples and see
[14:19] <rick_h_> I looked at a rename here, but it hit some 50 files and I didn't want to get into it with this
[14:19] <rick_h_> because we've started a lp.ui namespace and this would be good as lp.ui.banner.PrivacyBanner, lp.ui.banner.BetaBanner, etc
[14:19] <rick_h_> but for another day
[14:22] <jcsackett> rick_h_: ping. i lost history in irc, so the details as to why you needed me to ping you are lost to me. what's up?
[14:22] <abentley> rick_h_: Why attach the _singleton_privacy_banner to window?
[14:23] <rick_h_> abentley: to be explicit. That's what's happening itself, but making it explicit makes sure in all cases you're using a global instance
[14:23] <rick_h_> jcsackett: sorry, ping'd earlier because I didn't get how banner rendering worked with the .pt bits
[14:23] <danilos> deryck, hi, I've filed a few bugs related to specification privacy: bug 1056881, bug 1056891 and bug 1056893 - sorry if I made any duplicates, but I didn't find them
[14:23] <_mup_> Bug #1056881: Specifications privacy: subscribers can't see private blueprints <Launchpad itself:New> < https://launchpad.net/bugs/1056881 >
[14:23] <_mup_> Bug #1056891: Specification privacy: upcoming work won't load for anyone if there's any private data on it <Launchpad itself:New> < https://launchpad.net/bugs/1056891 >
[14:23] <_mup_> Bug #1056893: Specification privacy: no "private content" header on +upcomingwork page with private data <Launchpad itself:New> < https://launchpad.net/bugs/1056893 >
[14:23] <rick_h_> jcsackett: but basically just ping'd on the review since you looked at it yesterday with feedback
[14:24] <rick_h_> jcsackett: feel free to ignore
[14:24] <jcsackett> rick_h_: so all is well now? i'm happy to answer questions whenever. it's not the clearest of code, despite my best efforts at the time. :-P
[14:25] <rick_h_> jcsackett: well, I broke off rendering into a second step. Just events for now
[14:25] <jcsackett> rick_h_: dig.
[14:25] <rick_h_> so might bug you later on, but for now I"m cool
[14:25] <jcsackett> rick_h_: righto.
[14:26] <abentley> rick_h_: I don't understand the value of that explicitness.   It's to make sure you know where that's at and prevents people from looking for var definitions and such
[14:26] <rick_h_> for instance, in tests, I know I need to reset that window.var
[14:29] <deryck> danilos, thanks for filing the bugs.
[14:29] <abentley> rick_h_: Window is just a global.  It doesn't ensure there's only one instance of PrivacyBanner.  If I can set __singleton_privacy_banner to null, then getPrivacyBanner will create a second instance.
[14:29] <rick_h_> abentley: right, but the module is only loaded once. So it's set to null one on module load. And then never again
[14:29] <danilos> deryck, yw, thanks for getting this in, Linaro wants to use it asap :)
[14:30] <rick_h_> except in tests where I do that to do a proper teardown
[15:06] <abentley> rick_h_: Sorry, forgot I was reviewing before the call.
[15:06] <rick_h_droid> np
[15:12] <abentley> rick_h_: It doesn't seem very decoupled to be emitting privacy_banner:hide/privacy_banner:show.  If you know about the privacy banner, why not ns.getPrivacyBanner()._make_public ?
[15:14] <rick_h_> abentley: because in that case you need to deal with the instance
[15:14] <rick_h_> abentley: the future branch will get rid of the singleton code so you won't call anything. You'll just fire the event.
[15:15] <rick_h_> and ideally, you'll be firing the information type event, not the privacy banner event
[15:15] <rick_h_> so the calling code won't be using _make_public. What you'll have is banners and portlets listening for information_type:change/is_public/is_private events
[15:15] <abentley> rick_h_: Okay, makes sense.
[15:24] <abentley> rick_h_: r=me.
[15:24] <rick_h_> abentley: cool thanks for the review
[16:03] <jcsackett> abentley: you available to look at a branch that just fixes up sampledata?
[16:03] <abentley> jcsackett: sure.
[16:03] <jcsackett> abentley: awesome. :-) https://code.launchpad.net/~jcsackett/launchpad/remove-date_next_suggest_packaging-needs-sampledata/+merge/126475
[16:04] <abentley> jcsackett: r=me.
[16:04] <jcsackett> abentley: thanks!
[16:10] <robbiz^> Hi guys! I've some problems installing launchpad on my laptop, with chroot and rocketful-setup
[16:10] <robbiz^> can I ask someone of you how to fix it?
[16:22] <czajkowski> robbiz^: you might have more luck if you start to explain whats going on
[16:23] <czajkowski> or else posting to launchpad-dev mailing list
[16:24] <czajkowski> robbiz^: https://launchpad.net/~launchpad-dev
[16:25] <robbiz^> Ok...
[16:27] <robbiz^> Well my  postgresql database didn't start
[16:27] <robbiz^> the message is this
[16:28] <robbiz^> Error: The cluster is owned by user id 120 which does not exist any more
[16:29] <robbiz^> going through system folders I've no config file in /etc/postgresql/9.1/main
[16:34] <robbiz^> I have Ubuntu precise with chroot system as explained in dev.launchpad.net
[16:46] <jcsackett> sinzui: you free to talk for a bit?
[16:47] <sinzui> yes
[16:50] <robbiz^> Ok... Probably it's better to post on the mailing-list!
[16:50] <robbiz^> :)
[17:18] <sinzui> jcsackett, ding dong
[17:22] <sinzui> jcsackett, I think this test should pass, but it does not. It might be the origin of the 404 because mail rationales and canonical urls are need to explain why the email as received: http://pastebin.ubuntu.com/1228850/
[17:37] <jcsackett> sinzui: awesome.
[20:00] <lifeless> jcsackett: 'When this is improved' ? <- approved??
[21:33] <jcsackett> lifeless: Sample data branch?
[21:39] <jcsackett> lifeless: approved, yes.
[21:54] <lifeless> jelmer: hey, still interested in packaging lptools ?
[21:55] <jelmer> hi lifeless
[21:55] <jelmer> lifeless: no, not really after wheezy
[21:58] <lifeless> jelmer: have you been using bzr builddeb etc for it, or just regular packaging ?
[21:58] <lifeless> jelmer: I see 'new upstream snapshot' in the log - can't quite tell :)
[21:59] <jelmer> lifeless: I only use bzr builddeb for packages in bzr so that must be what I was using :-)
[21:59] <lifeless> jelmer: also, I haven't used the debian bzr facilities for a couple years - whats the current stuff for pushing there...
[21:59] <lifeless> jelmer: or perhaps I can convince you to do the upload of 0.2.0 and ITA it at the same time ?
[21:59] <jelmer> the last branch is @ http://anonscm.debian.org/bzr/bzr/collab-maint/lptools/unstable/
[22:00] <jelmer> lifeless: Sure, I'm happy to do another upload
[22:00] <jelmer> lifeless: do you mean RFA rather than ITA?
[22:00] <lifeless> yes, crossed wires
[22:00] <lifeless> I was thinking intent to abandon :)
[22:01] <jelmer> lol
[22:01] <jelmer> lifeless: but sure, happy to do another upload with 0.2.0 and the RFA
[22:02] <lifeless> jelmer: that would be awesome, thank you
[22:02] <lifeless> let me file it
[22:08] <lifeless> jelmer: actually, I'm going to O it
[22:09] <jelmer> lifeless: euhrm, okay
[22:09] <lifeless> jelmer: I doubt there will be another upload before I finish here
[22:09] <lifeless> jelmer: and after that I'll have other things to worry about, so saying I'd maintain it in the interim would be an exaggeration
[22:10] <jelmer> lifeless: sounds reasonable to me
[22:10] <lifeless> http://www.debian.org/devel/wnpp/ : "RFA...hey will maintain it in the meantime, but perhaps not in the best possible way. In short: the package needs a new maintainer. "
[22:10] <jelmer> lifeless: I originally thought that's what you meant
[22:10] <lifeless> vs
[22:10] <lifeless> O
[22:10] <lifeless> The package has been "Orphaned". It needs a new maintainer as soon as possible
[22:10] <czajkowski> wgrant: see pm
[22:10] <jelmer> since I think a RFA doesn't require changes to the package itself
[22:10] <lifeless> jelmer: I'm not sure O does either does it ?
[22:11] <lifeless> jelmer: adoption requires the change
[22:11] <jelmer> lifeless: it does, requires changing the maintainer to Debian QA team
[22:11] <lifeless> huh, inconsistent docs ftw
[22:11] <lifeless> jelmer: so, whats easiest for you?
[22:12] <jelmer> lifeless: if you file the O bugreport I can do an upload that changes the maintainer to the QA team
[22:12] <lifeless> will do
[22:16] <lifeless> jelmer: just waiting for the ack
[22:18] <lifeless> jelmer: bug 688916
[22:18] <_mup_> Bug #688916: 75-80% CPU-Usage (starting with 1.9.0beta1) <cpu> <Mixxx:Invalid> < https://launchpad.net/bugs/688916 >
[22:18] <lifeless> well, not that one :P
[22:20] <jelmer> (-:
[22:21] <jelmer> we've given up on critical bugs?
[22:21] <StevenK> Hm
[22:58] <sinzui> wgrant, https://code.launchpad.net/~sinzui/launchpad/bug-subselect-timeout/+merge/126566
[23:10] <StevenK> wallyworld__: http://theamazingios6maps.tumblr.com/
[23:16] <sinzui> jcsackett, r=me
[23:17] <jcsackett> sinzui: awesome, thansk.
[23:19] <sinzui> StevenK, https://devpad.canonical.com/~curtis/launchpad-critical-report/launchpad-criticals.html is updated.
[23:33] <StevenK> wgrant: So, lp-setup-lxc-build actually does a build
[23:34] <wgrant> StevenK: Is the build successful?
[23:35] <StevenK> It looks to run make schema too, it looks fine
[23:36] <StevenK> wgrant: lxc-stop: failed to stop 'lptests': Operation not permitted and ls: cannot access lptests: No such file or directory are a little concerning
[23:37] <wgrant> StevenK: You sure it's adequately root?
[23:37] <StevenK> wgrant: It's running under sudo ...
[23:37] <elmo> apparmor
[23:38] <StevenK> sudo lxc-stop -n lptests does not complain
[23:38] <StevenK> I may have to reach for set -x or run 'id' in the script
[23:39] <wgrant> The apparmor workaround shouldn't be necessary to get this bit working
[23:39] <wgrant> Just some stuff inside the container
[23:39] <wgrant> Like postgres
[23:39] <wgrant> And I think lpsetup does the apparmor disablement.
[23:39] <StevenK> Apparently not for nested
[23:39] <StevenK> According to the README
[23:39] <StevenK> But who reads those anyway
[23:43] <StevenK> wgrant: So the next step is to fire up lp-setup-lxc-tests?
[23:45] <wgrant> StevenK: Right, fill in the lp-setup-lxc-test template and then run something like 'lp-setup-lxc-tests -t lp.services.config' and see what happens
[23:46] <StevenK> Pain, misery and suffering is my guess
[23:46] <wgrant> And/or great success.
[23:46] <StevenK> Well, those aren't mutally exclusive. :-)
[23:53] <wgrant> StevenK: Any luck?
[23:53] <StevenK> wgrant: Just about to run it
[23:54] <StevenK> BLEH
[23:54] <StevenK> Forgot {ssh_key_path}
[23:55] <wgrant> Heh
[23:55] <wgrant> It's easy to do
[23:58] <StevenK> Rargh, single quotes


[02:20] <xnox> robert_ancell: i don't like the new wallpaper, or unity-greeter, or both together.
[02:21] <robert_ancell> xnox, ?
[02:21] <xnox> robert_ancell: the dot patters doesn't line-up with suru/origami guide-lines and the circle of friends is not in the center of the suru cross.
[02:22] <xnox> robert_ancell: either one or both of these are missaligned, or we have a bug/regression in the toolkits somewhere.
[02:22] <robert_ancell> ah
[02:22] <robert_ancell> file a bug :)
[02:23]  * xnox things of the title
[02:23] <robert_ancell> "Default wallpaper does not align well with greeter grid"
[02:28] <desrt> robert_ancell: any plans to continue porting the games to new tech?
[02:28] <desrt> i noticed today that aisleriot still uses gconf....
[02:28] <robert_ancell> desrt, which games?
[02:29] <robert_ancell> desrt, I don't work on them anymore, but the main games are being actively ported
[02:29] <robert_ancell> aisleriot got split off, so I think it's stagnating as much as it always was
[02:30] <robert_ancell> desrt, did you ever look at those gsettings editor changes I made?
[02:30] <desrt> ah... no
[02:31] <xnox> robert_ancell: bug #1291735
[02:31] <ubot2`> Launchpad bug 1291735 in unity-greeter (Ubuntu) "Default 14.04 wallpaper does not align well with greeter grid" [Undecided,New] https://launchpad.net/bugs/1291735
[02:32] <desrt> robert_ancell: this is not bad
[02:38] <desrt> robert_ancell: the idea of adding summary/description to schemas is interesting
[02:38] <desrt> maybe could add some more structural information too
[02:38] <desrt> like belongs-to-desktop-id or so
[02:38] <robert_ancell> yeah
[02:38] <robert_ancell> I couldn't see any downside to doing it
[02:39] <desrt> i have some ideas for a version 2 of the schema file starting to add up
[02:41] <robert_ancell> xnox, did you assign to mpt for a specific reason?
[03:10] <xnox> robert_ancell: yeap, the wallpaper is buggy, I agree with you =) and i've now generated images showing the bull's eye and rough offsets.
[03:11] <robert_ancell> xnox, they may have offset it on purpose, because that might made it look less rigid. But with the grid on top we emphasise the offset
[03:11] <robert_ancell> xnox, because in general you should open a task against the ayatana-design project so any designer can see it
[03:13] <xnox> robert_ancell: i never touch ayatana-design tasks. Most of the time, it's bug updates by JL demanding things that got rejected by desktop team / TechBoard / mark.
[03:13] <xnox> robert_ancell: i thought "needs-design" was the tag to get designers attention =/
[03:14] <robert_ancell> xnox, perhaps the process changed :)
[03:15] <xnox> i don't like this border-less stuff =) i've got confused between "emacs full screen with two buffers" vs "two emacs windows, each snapped to half-screen"
[03:15] <xnox> I guess, i'll get used to it =)
[03:16]  * xnox ponders if i can tripple the shadow
[03:36] <RAOF> Why, hello libhybris!
[03:38] <RAOF> I take it there's not a lot of testing of unity8-desktop-session-mir, then.
[05:40] <pitti> Good morning
[08:49] <mlankhorst> seb128: https://bugs.launchpad.net/ubuntu/+source/xinput/+bug/1287341 needs fixing in some other layer, the transformation matrix needs to be set..
[08:49] <ubot2`> Launchpad bug 1287341 in xinput (Ubuntu) "Touchscreen controls both screens in dual-monitor setup" [Undecided,Incomplete]
[08:50] <seb128> good morning desktopers
[08:50] <mlankhorst> should I reassign it to gnome-settings?
[08:50] <seb128> hum, I guess unity-settings-daemon/gnome-settings-daemon should do that, but why can't xorg do the right thing?
[08:51] <mlankhorst> it does by scaling it over the entire screen :P
[08:52] <mlankhorst> https://bugzilla.gnome.org/show_bug.cgi?id=698284 I think
[08:52] <ubot2`> Gnome bug 698284 in xrandr "Missing feature causes weird behavior when using touchscreen when two (or more) monitors are present" [Normal,Unconfirmed]
[08:53] <seb128> so why is the output not matching?
[08:56] <mlankhorst> poking the xi maintainer some more it seems garnacho is working on it
[08:57] <seb128> cool
[08:57] <seb128> that still seems wrong
[08:57] <seb128> it means every desktop environment has to implement the same logic
[08:57] <seb128> input should just match the screen, without needed a specific desktop/client code
[08:57] <mlankhorst> they also have to map things like output providers / render slaves
[09:02] <seb128> hum, k, I don't know the details of the input stack, but it still seems wrong that input doesn't match screen out of the box, e.g that you have to rely on desktop code to make things work for you
[09:03] <seb128> because it means GNOME, KDE, xfce, ldme, lightdm, etc are all going to need to add the same "transformation matrix code"
[09:03] <seb128> which is just nonsense
[09:22]  * mlankhorst didn't write the code :/
[09:24] <RAOF> seb128: Oh, ho ho ho!
[09:24] <seb128> RAOF, hey, how are you?
[09:24] <RAOF> seb128: There's no way to map between the display panel and the touch input device.
[09:24] <RAOF> Because hardware is hateful.
[09:25] <seb128> :-(
[09:25] <RAOF> seb128: Hey!
[09:25] <seb128> there is also no way to have a more common component/something not desktop specific?
[09:26] <RAOF> Well, you could, but you absolutely have to expose a user-visible preference, because any heuristic will be wrong in some cases.
[09:26] <RAOF> So there's going to be a desktop-specific component to any solution.
[09:27] <seb128> does that need calibration?
[09:27] <RAOF> Not so much calibration as ‘which monitor is this input device attached to?’
[09:29] <seb128> so we need a piece of UI as well to do that?
[09:29] <RAOF> Yeah.
[09:29] <seb128> it means it can't work out of the box/has to prompt you when you connect a new monitor?
[09:30] <RAOF> Weeeell.
[09:30] <RAOF> You *can* do some heuristics (which is what I intend to do in Mir), like ‘did a touchscreen-like input device show up at the same time as this monitor was plugged in’?
[09:31] <seb128> I guess you can do guessing, like if you have a touch input and one screen only, match them, if you add new devices that a non touch assume the input should still match the first one
[09:31] <RAOF> But, no, if everything's plugged in on first boot, you can't get it to reliably work out of the box (this also affects Windows)
[09:31] <seb128> :-(
[09:31] <RAOF> Yes.
[09:31] <RAOF> I have no idea how MS hasn't written a hardware spec for this.
[09:32] <seb128> why is tech so lame? by now you would expect that new hardware don't come out without a way for the OSes to deal properly with them :/
[09:32] <RAOF> It's not like they've not spent a huge amount of effort pissing off their existing users to move to a touch interface or anything.
[09:33] <RAOF> This wasn't so much of a problem when there weren't external touchscreens available.
[09:33] <RAOF> Because then ‘is it an internal display?’ is a very good guess.
[09:33] <seb128> right
[09:35] <RAOF> And you only had to deal with the reasonably rare hateful cases where that didn't apply :)
[09:36] <seb128> well, if I read the bug pointed earlier correctly, atm we do the wrong thing if you have a touch laptop and dock it
[09:36] <seb128> but I guess that's where we need code in g-s-d
[09:55] <davmor2> anyone else have FF using 200% cpu on trusty when you close it, especially after a hangout?
[10:18] <seb128> andyrock, hey
[10:19] <seb128> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1291088
[10:19] <ubot2`> Launchpad bug 1291088 in unity (Ubuntu) "Doesn't unlock when coming back from the greeter" [High,Triaged]
[10:19] <seb128> how do you try?
[10:24] <mlankhorst> can I increase the upstart timeout before it sends SIGKILL?
[10:26] <jodh> mlankhorst: 'kill timeout <seconds>'.
[10:26] <mlankhorst> ah ty
[10:32] <tkamppeter> larsu, hi
[10:37] <mlankhorst> argh no way to increase timeout for lightdm killing X >:(
[11:29] <seb128> dobey, hey, could you review the patch on https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1244493?
[11:29] <ubot2`> Launchpad bug 1244493 in software-center (Ubuntu) "Software Center doesn't save settings on Saucy" [High,Confirmed]
[11:30] <ogra_> hmm, i can see the shadows cut off on the launcher tooltips since the last upgrade
[11:32] <ogra_> (everywhere where there is bright bg behind them ... )
[11:32] <seb128> ogra_, yeah, seems a new bug indeed
[11:32] <andyrock> seb128: hey
[11:32] <seb128> andyrock, hey
[11:32] <andyrock> seb128: i just login as "User1"
[11:33] <andyrock> seb128:switch account using session indicators (let's say User2)
[11:33] <andyrock> now I'm in the unity-greeter
[11:33] <seb128> ogra_, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1291838
[11:33] <ubot2`> Launchpad bug 1291838 in unity (Ubuntu) "Wrong Launcher tooltips decorations/shadows" [Undecided,Confirmed]
[11:33] <andyrock> move back to User1 using lightdm
[11:33] <andyrock> session in unlocked
[11:33] <seb128> :-(
[11:33] <seb128> for me it's locked
[11:33] <seb128> I do
[11:33] <seb128> - start my session
[11:33] <ogra_> seb128, ah, perfect, thanks
[11:34] <seb128> - go to the indicator-session, click on "testuser"
[11:34] <seb128> -> that brings me to the greeter with "testuser" selected
[11:34] <seb128> - move back to "normaluser"
[11:34] <seb128> - type my password
[11:34] <seb128> -> back to the session with unity locked
[11:35] <andyrock> I'll ask Trevinho if I can reproduce it
[11:35] <andyrock> it's that lightdm should emit logind signal "Unlock"
[11:36] <seb128> weird that we see different behaviour though, I'm on trusty with everything from the archive uptodate
[11:37] <andyrock> you're using unity from repo right?
[11:38] <andyrock> launching it in the normal way
[11:38] <andyrock> not from a tty
[11:38] <andyrock> or stuff like that
[11:50] <andyrock> seb128:^^^^
[11:56] <seb128> andyrock, yes, boot, log in using lightdm (not autologin)
[12:03] <davmor2> seb128: am I correct in assuming that the new lock screen is lightdm I'm having issues with it and the screen blanking
[12:03] <seb128> davmor2, no it's not, it's unity, what issues?
[12:05] <davmor2> seb128: if I leave it for 5 minutes it should blank, but instead displays the unlock screen, if I unlock it 2-3 seconds later the screen blanks and I have to unlock it again.  If I hit ctrl+alt+l it used to blank the screen again now it just displays the lock screen
[12:06] <seb128> Trevinho, andyrock: ^
[12:06] <seb128> davmor2, you should open a bug about it
[12:06] <seb128> davmor2, what are you setting for turn off and lock screen?
[12:06] <davmor2> seb128: hence me asking what it was part of :)
[12:07] <xnox> mpt: hello! I have a bug report against the new default wallpaper =) while it clearly has a center point, it's not in the center. bug #1291735
[12:07] <ubot2`> Launchpad bug 1291735 in ubuntu-wallpapers (Ubuntu) "Default 14.04 wallpaper does not align well with greeter grid" [High,Confirmed] https://launchpad.net/bugs/1291735
[12:07] <davmor2> seb128: default settings I've not modified anything
[12:07] <xnox> mpt: thus it looks odd, when greeter dot pattern & circle of friends are applied on top of it (as those are centered perfectly)
[12:10] <seb128> davmor2, the default setting is to turn off & lock after 5 minutes, seems to be what you describe
[12:11] <seb128> davmor2, if it was not locking before then it was buggy and the current behaviour is correct
[12:11] <davmor2> seb128: no it was blanking before you move the mouse or hit a key and the lock screen would appear
[12:12] <seb128> blanking before you hit a key?N
[12:12] <seb128> I don't understand the concept :p
[12:12] <davmor2> seb128: now instead it isn't blanking it is displaying the lock screen, then it blanks after you unlock it
[12:12] <seb128> I can't confirm that
[12:12] <seb128> for me it fades the screen after the timeout
[12:12] <seb128> once the screen is off it's locked
[12:12] <seb128> if I move the mouse it turns the screen on
[12:12] <davmor2> seb128: I'll write the bug and then take a video of saucy and trusty
[12:12] <seb128> if I type my password I've my session
[12:13] <seb128> don't bother taking a video of saucy
[12:13] <seb128> having one of trusty would help (make sure you have uptodate, maybe check in a new user session)
[12:13] <davmor2> seb128: no I meant as a comparison for what I expect to happen and was happening on trusty
[12:14] <davmor2> seb128: it could be the optimus gfx that are causing the issue maybe
[12:14] <seb128> right, don't bother doing the saucy one
[12:14] <seb128> we know what's expected
[12:28] <davmor2> seb128: ofcourse now I want to video it, it is working perfectly sods law I record it if it happens again
[12:28] <seb128> haha
[12:28] <seb128> ok, thanks
[12:29] <seb128> davmor2, did you reboot since the recent update? I wonder if you maybe still had the old gnome-screensaver running or something
[12:29] <davmor2> seb128: ah could be
[12:31] <davmor2> might be a race as to what blanks it first gnome or unity which would explain to 2 logins
[12:32] <seb128> we patched gnome-screensaver to call unity locking under unity
[12:32] <seb128> so that should not happne
[12:41] <tkamppeter> larsu, around?
[12:43] <seb128> tkamppeter, you probably just better ask your question so he can reply when he reads scrollback
[12:44] <seb128> bregma, hey, how do you guys track bugs to fix for trusty in unity/what's the best way to point the "that's a regression we need to fix before release"?
[12:45] <tkamppeter> larsu, seb128, there seems to be a problem with whatever icon pops up on Xubuntu when something is printed, see bug 1291075. CUPS does its job correctly as the printout comes correctly out of the printer, the problem is the desktop icon. To which package do I have to assign this bug?
[12:45] <ubot2`> Launchpad bug 1291075 in cups (Ubuntu) "printer icon does not disappear" [Undecided,Confirmed] https://launchpad.net/bugs/1291075
[12:48] <seb128> tkamppeter, I don't know, maybe ochosi can help you
[12:48] <tkamppeter> ochosi, ^^^
[12:51] <davmor2> seb128, Trevinho, andyrock: Okay so after a reboot the screen blanking is kicking in correctly \o/ however ctrl+alt+l isn't blanking the screen like it used to it is just displaying the unlock screen is that deliberate or not do you know?
[12:51] <larsu> tkamppeter: I don't know either, sorry
[12:52] <seb128> davmor2, seems like worth reporting a bug
[12:52] <davmor2> seb128: will do
[12:52] <seb128> thanks
[12:52] <mdeslaur> seb128: so bug 1291370 is a regression in unity-gtk-module
[12:52] <ubot2`> Launchpad bug 1291370 in unity-gtk-module (Ubuntu) "in virtual-manager, the global-menu or local integrated menus stopped working in the vm-display" [Undecided,Confirmed] https://launchpad.net/bugs/1291370
[12:53] <seb128> mdeslaur, from what version?
[12:53] <mdeslaur> seb128: the latest one, I put the version that worked in the bug
[12:53] <seb128> shrug
[12:54] <seb128> mdeslaur, thanks for figuring that out
[12:54] <mdeslaur> np, thanks in advance for fixing it ;)
[12:56] <seb128> mdeslaur, stop using old gtk2 softwares btw :p
[12:56] <mdeslaur> seb128: you mean like firefox? ;)
[12:56] <jibel> seb128, do you know if there is a more detailed test plan than https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-settings for system settings?
[12:56] <seb128> mdeslaur, for example :p
[12:56] <mdeslaur> hehe
[12:57] <seb128> jibel, there isn't
[12:57] <jibel> thanks
[12:57] <seb128> jibel, what sort of details are you missing? it's basically "run autotests, check manually things that changed"
[12:57] <seb128> jibel, I'm open to suggestions on what else you would like to see there
[13:03] <jibel> seb128, I'm looking for a list of user stories or a high level test cases that could be used to determine what should be tested, what can be automated and what cannot, this sort of thing.
[13:03] <jibel> seb128, the best doc I could find is https://wiki.ubuntu.com/SystemSettings
[13:04] <seb128> jibel, https://blueprints.launchpad.net/ubuntu/+spec/client-t-system-settings-testing is a the items we listed that would be nice to test
[13:04] <seb128> those are not really "user story oriented" though
[13:05] <seb128> they are specific widgets/actions to test rather than user journeys
[13:27] <ochosi> tkamppeter: i don't have a printer (and also no network printer) here, but i'll try to look at it as soon as i can
[13:28] <seb128> ochosi, hey, do you know what component is used by xubuntu, is that system-config-printer-applet? indicator-printer? xsomething?
[13:28] <ochosi> by default in 13.10 we only had indicator-application
[13:28] <ochosi> because we were restricted to gtk2 indicators
[13:28] <seb128> but you have support for the notification area
[13:29] <seb128> so you could be using system-config-printer-applet?
[13:29] <ochosi> and system-config-printer-applet
[13:29] <seb128> k
[13:29] <seb128> that's probably the printer icon there
[13:29] <ochosi> i think that one goes through either tray or indicator-application
[13:29] <ochosi> not sure now, i frankly haven't had a printer @home for quite a while...
[13:29] <seb128> seems like the bug should be reassigning to system-config-printer
[13:29] <seb128> which was the question I think
[13:29] <ochosi> ah ok
[13:29] <ochosi> yeah, in that case that seems the obvious choice
[13:30] <seb128> reassigned*
[13:30] <seb128> ochosi, thanks
[13:30] <seb128> tkamppeter, ^
[13:31] <ochosi> no problem!
[13:32] <tkamppeter> ochosi, thank you very much.
[13:33] <ochosi> tkamppeter: can you check whether that still happens in 14.04?
[13:33] <ochosi> would be nice to get this fixed before the release
[13:34] <ochosi> tkamppeter: if it really still applies to trusty, please then link it to this blueprint: https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-t-bugs
[13:34] <ochosi> and for the rest, head over to #xubuntu-devel, no need to spam these nice folks' channel ;)
[13:36] <tkamppeter> ochosi, I do not have Xubuntu here.
[13:37] <ochosi> ok
[13:41] <tkamppeter> ochosi, seb128, I have reassigned the bug to s-c-p now and asked the original author (Tim Waugh) for help on debugging this.
[13:42] <seb128> tkamppeter, thanks
[14:45] <andyrock> seb128, i can reproduce the bug
[14:45] <andyrock> i'm working on it
[14:45] <seb128> andyrock, oh, what did you change?
[14:54] <andyrock> seb128, i reinstalled gnome-screensaver
[14:57] <seb128> shrug, disconnects
[14:57] <seb128> tedg, kenvandine, larsu, charles, attente: I delete the settings meeting for today, vUDS ... but I just realized you guys might want to have one anyway (if you don't have sessions)
[14:57] <seb128> andyrock, so your version was maybe different from the only we landed?
[14:57] <seb128> (not sure that went through before)
[14:57] <larsu> seb128: I'm fine thanks. I finally got around to pushing that rhythmbox MR if you have some time
[14:58] <seb128> larsu, great, I've another session to lead now but then I can have a look
[14:58] <larsu> cool
[15:01] <kenvandine> seb128, nothing from me
[15:12] <nessita> hello everyone! so long. kenvandine, question: were you able to workaround the issue we were having yesterday when trying to watch live streams of UDS sessions? ("An erro occurred please try again later")
[15:12] <seb128> nessita, hey! it has been a while, how are you?
[15:12] <kenvandine> nessita, incognito mode in chrome worked for me
[15:13] <nessita> kenvandine, oh, I tried that, no luck for me
[15:13] <nessita> seb128, hola!!!! I'm pretty good -- one year older! as every year :-D
[15:13] <nessita> you?
[15:13] <seb128> nessita, just got your birthday?
[15:13] <seb128> nessita, I'm good thanks
[15:13] <nessita> seb128, today! still crying, though :-P
[15:14] <seb128> nessita, happy birthday! don't cry :-(
[15:15]  * seb128 hugs nessita
[15:15]  * nessita hugs seb128
[15:16] <seb128> I can see a chrisccoulson!
[15:29] <seb128> bregma, did you see my questions about unity bugs tracking earlier today btw?
[15:30] <bregma> seb128, yes: any lockscreen bugs should be tagged with 'lockscreen' because those are the priority right now, else we target them for the upstream Unity 7.2 release
[15:30] <seb128> bregma, so you want bugs on upstream component and ubuntu?
[15:31] <seb128> I noticed for lockscreen, but I've some that are not with it
[15:31] <seb128> like the launcher tooltips looking wrong
[15:31] <seb128> or the ">" in the launchers being out of sync with reality sometimes
[15:32] <seb128> dobey, hey, did you see the s-c bug/patch I pointed earlier?
[15:33] <dobey> seb128: yeah. will look at it
[15:33] <seb128> dobey, thanks
[15:38] <mlankhorst> ok that was terrible, i had to check the desktop background settings to make sure that I didn't regress mesa with my mesa 10.1 in the ppa
[15:38] <mlankhorst> who came up with triangles for the trusty background? :o
[15:47] <desrt> seb128: any update on the gsettings crasher?
[15:47] <desrt> i'd like to tuck that into the next release if possible
[15:50] <ochosi> quick question: do you guys use button-images in general in unity or not? (i.e. ButtonImages=1)
[15:51] <ochosi> just wondering cause there's a change in how gtk3 aligns labels in buttons (now they're baseline-aligned instead of vertically centered) and it looks a bit bad with icons
[15:52] <ochosi> here's an illustration of what i mean: http://www.zimagez.com/zimage/screenshot-2014-03-13-164642.php
[15:52] <ochosi> (it looks the same with ambiance, but yeah, this is adwaita)
[15:53] <seb128> desrt, when is the next release? I uploaded to the desktop team ppa bit earlier, waiting for that to build and giving you my +1 soon
[15:54] <desrt> seb128: monday
[15:54] <seb128> desrt, ok, so that should be fine, you are going to be my feedback before eod today
[15:54] <desrt> excellent
[15:54]  * desrt doing end-of-cycle cleanups
[16:00] <Sweetshark> seb128: libreoffice autopkgtests are (almost) running again.
[16:00] <seb128> Sweetshark, nice, what's the almost?
[16:00] <Sweetshark> seb128: (just some broken deps, that should be easy to fix)
[16:02] <Sweetshark> seb128: broken in the sense of "some needless autogenerated deps in the helper package (libreoffice-subsequentcheckbase) that we use"
[16:02] <seb128> k
[16:24] <davmor2> seb128: bug 1292069 has been filed so I confirmed it but I think it and it could link to bug 1292078
[16:24] <ubot2`> Launchpad bug 1292069 in Unity "After locking the screen manually (Ctrl+Alt+L), then walking away, need to unlock twice" [Undecided,Incomplete] https://launchpad.net/bugs/1292069
[16:24] <ubot2`> Launchpad bug 1292078 in unity (Ubuntu) "New lock screen is shown on ctrl+alt+l rather than blanking the screen" [Undecided,New] https://launchpad.net/bugs/1292078
[16:35] <GunnarHj> Hi seb128!
[17:47] <lifeless> hmm, my laptop now suspends when I close the lid, even though I've used gnome-control-center to tell it to 'do nothing'
[17:47] <lifeless> Any suggestions on how to debug this?
[18:42] <seb128> davmor2, ok
[18:42] <seb128> GunnarHj, hey
[18:43] <GunnarHj> seb128: What do you think about this new shortcut thing at first login?
[18:43] <seb128> lol
[18:43] <seb128> GunnarHj, I knew you wouldn't like for guest sessions ;-)
[18:44] <seb128> it's useful, not sure it should happen in a guest session though
[18:44] <seb128> having it stack on top of the dialog that the guest session opens looks buggy
[18:45] <GunnarHj> seb128: Right, for the guest session it's extra bad. But I doubt that it's the kind of guidance that new Ubuntu users ask for at first hand.
[18:45] <GunnarHj> seb128: Do you know what kind of flag that stops it from showing up later on?
[18:46] <seb128> GunnarHj, I'm not sure, open a bug about it I guess
[18:46] <seb128> no, but bregma or Trevinho might know
[18:47] <bregma> GunnarHj, there's a file in XDG_CONFIG_DIR that gets created to prevent it from showing
[18:48] <bregma> GunnarHj, open a bug so we can track this problem please
[18:48] <GunnarHj> bregma: Thanks! Guess I could use that to propose something that stops it in guest session.
[18:48] <GunnarHj> bregma: Will open a bug as well.
[18:58] <seb128> bregma, btw what that a design request? it feels like a first start dialog, which we decided to not do long ago ... if we revisit that it seems like we might have more things to communicate to users than keybindings
[18:59] <seb128> bregma, it also feels like that should have been through a ffe ... ;-)
[19:26] <GunnarHj> seb128: It's a "fix" of bug 1283619
[19:26] <ubot2`> Launchpad bug 1283619 in Unity "No "first run" tutorial for Unity/Ubuntu" [High,In progress] https://launchpad.net/bugs/1283619
[19:27] <GunnarHj> seb128, bregma: I filed bug #1292178 about the guest session conflict.
[19:27] <ubot2`> Launchpad bug 1292178 in unity (Ubuntu) "New shortcut hint conflicts with startup dialog in guest sessions" [High,New] https://launchpad.net/bugs/1292178
[20:57] <GunnarHj> bregma: still there?
[20:59] <apw> https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1292217
[20:59] <ubot2> Launchpad bug 1292217 in lightdm (Ubuntu) "lightdm screen lock has triggered but keyboard is still connected to the main session" [Undecided,New]
[20:59] <apw> who owns lightdm as a screensaver issues, as i have a laptop which is letting me type through the screensaver
[21:07] <bschaefer> apw, the new lock screen?
[21:07] <bschaefer> apw, if so the current tagged list of bugs: https://bugs.launchpad.net/ubuntu/+source/unity/+bugs?field.tag=lockscreen
[21:07] <bschaefer> apw, if its a new bug please file it against unity with a lockscreen tag :)
[21:39] <desrt> seb128: hey.  update?
[21:40] <seb128> desrt, hey, works fine from what I can tell! I was not able to trigger the issue so I can't confirm it's fixed, but computer/session works without any visible issue
[21:41] <desrt> cool
[21:41] <desrt> i'll roll it into monday's release, then
[21:41] <desrt> it seems pretty 'safe' to me, fwiw
[21:41] <desrt> but i appreciate the testing just incase of some stupid mistake
[21:42] <seb128> right, thanks
[21:42] <desrt> no.  thank YOU

[21:42] <seb128> I'm going to upload it to trusty and watch errors.ubuntu.com
[21:42] <seb128> desrt, oh, sorry, did you just accidentally bump into me? ;-)
[21:42] <desrt> seb128: that's sorry
[21:43] <seb128> I just said that!
[21:43] <desrt> but it's probably my fault that you had the wrong information.  sorry about that.
[21:43] <seb128> ;-)
[21:43] <desrt> oh indeed.  you're right!  very sorry.
[22:05] <GunnarHj> robert_ancell: ping?
[22:05] <robert_ancell> GunnarHj, you can just ask a question..
[22:05] <GunnarHj> robert_ancell: Any spontaneous idea what causes the confusing behavior at bug 1292241?
[22:05] <ubot2> Launchpad bug 1292241 in unity (Ubuntu) "Using lightdm-gtk-greeter and still taken to unity-greeter" [Undecided,New] https://launchpad.net/bugs/1292241
[22:06] <robert_ancell> GunnarHj, look at lightdm.log and the config
[22:06] <robert_ancell> GunnarHj, oh, this is running Unity right?
[22:07] <robert_ancell> Unity now provides a screen lock
[22:07] <robert_ancell> I think there might be a bug where it doesn't drop it's lock sometimes when lightdm authenticates
[22:08] <seb128> robert_ancell, GunnarHj: bug #1291088
[22:08] <ubot2> Launchpad bug 1291088 in unity (Ubuntu) "Doesn't unlock when coming back from the greeter" [High,Triaged] https://launchpad.net/bugs/1291088
[22:08] <robert_ancell> there we go :)
[22:09] <GunnarHj> robert_ancell, seb128: Seems that the issue is addressed. Leaving it you you guys to sort it out. ;-)
[22:09] <seb128> GunnarHj, can you mark you bug as duplicate?
[22:10] <GunnarHj> seb128: Sure.
[22:10] <seb128> thanks
[22:11] <robert_ancell> seb128, have you ever looked into bug 1272977?
[22:11] <ubot2> Launchpad bug 1272977 in gtk+3.0 (Ubuntu) "gtk-update-icon-cache segfaults in gdk_pixbuf_io_init()" [High,Triaged] https://launchpad.net/bugs/1272977
[22:11] <robert_ancell> Seems quite common
[22:11] <robert_ancell> according to errors.ubuntu.com
[22:11] <seb128> robert_ancell, yes, I think it's a dist-upgrade issue
[22:11] <seb128> e.g versions mismatch in memory and disk
[22:12] <robert_ancell> oh, the loaders?
[22:12] <seb128> or mismatch because half the update happened and triggers are called
[22:12] <seb128> yeah, from what I saw it seemed like to happen on precise to trusty updates
[22:12] <seb128> so I guess there is a side effect of doing updates in sessions...
[22:13] <seb128> I might be wrong, but it seemed the reason why the retracings bts were not good as well
[22:22] <seb128> robert_ancell, got disconnected, not sure if you replied, I was saying that the failing retraces seemed to me because the running/disk versions mismatched
[22:22] <seb128> but I might be wrong
[22:22] <robert_ancell> seb128, yeah, it looks likely
[22:22] <seb128> not sure if there is anything we can do about that
[22:22] <robert_ancell> I wondered if they were being triggered on bad files, but I think what you've said is more likely
[22:22] <seb128> out of stopping to do update in session
[22:23] <robert_ancell> it should probably check the loaders version number and stop if they mismatch
[22:38] <apw> seb128, how do i unlock unity lockscreen from the command line, as i cannot from the prompts
[22:38] <seb128> apw, you can't afaik, why can't you from the prompts?
[22:38] <apw> seb128, cause my keyboard is connected to the applications behind it
[22:39] <seb128> how do you do that?!
[22:39] <apw> seb128, for instance i am typeig this text now though the lockscreen
[22:39] <seb128> weird
[22:39] <sarnold> .. and reading the responses?
[22:39] <apw> seb128, because it is compeltely broken i assume, and insecure
[22:39] <seb128> that's helpful
[22:39] <apw> sarnold, no, i have a second machine to read it
[22:39] <seb128> wfm
[22:39] <seb128> (as helpful)
[22:40] <apw> yeah, that
[22:40] <seb128> did you do anything special to get it in this state?
[22:40] <seb128> having steps to reproduce would help to debug
[22:40] <seb128> rather than "it's buggy and insecure"
[22:41] <seb128> but otherwise, no way to unlock that I guess, go to a vt and run "unity" to replace the running one?
[22:41] <apw> i left the machine to lock and this is what i got
[22:41] <apw> until i can unlock it i can't reproduce without rebooting etc
[22:41] <apw> if there is nothing interesting to be gained from its current state, then i can do that
[22:41] <seb128> did you have a context menu/special ui/something open?
[22:42] <apw> behind the lock ... hard to say
[22:42] <apw> thlugh alt-tab is "working" as in it pops the app selector
[22:42] <apw> and that normally doesn't work when menus are open does it ?
[22:42] <seb128> bregma, Trevinho, andyrock, ^ is there any info that would be useful?
[22:42] <seb128> it doesn't indeed
[22:43] <apw> my memory is upgrading, rebooting, logining in and setting up windows, moving to another machine leaving it to lock
[22:43] <apw> not even locking it, and coming back to this
[22:43] <apw> but ... i wasn't looking out for it
[22:43] <seb128> k
[22:44] <seb128> well, you are the first one to report the issue
[22:44] <apw> its quite a new change too mind you
[22:44] <seb128> with is good, because it's not everyone, but less good because it means there is a bug there that might be not easy to reproduce/debug
[22:44] <seb128> well, we got like 10 bug reports about other (minor) issues
[22:45] <seb128> I've also beeing locking and testing different scenarios on several machines since yesterday
[22:45] <seb128> including what happens on idle timeout, etc
[22:45] <seb128> never got that one
[22:45] <apw> so the other issue i have with it is it is not turning off the screen, so i will have to zap it before bed
[22:45] <seb128> right, that has been report and should be easy to fix
[22:45] <seb128> reported
[22:46] <apw> seems i can interact with my rhythmbox as well, but no i can do that on the working machine as well
[22:46] <bregma> apw, here's trick to unlocking until the window ordering bug is fixed (and the fix is in the works): select an indicator, then select the password field again
[22:47] <apw> bregma, that does indeed work
[22:47] <bregma> if you use alt-tab while the lock screen is on, input gets redirected to one of the apps behind the lock screen
[22:47] <bregma> which you need to hop is not your facebook status
[22:47] <apw> bregma, or in my case irc indeed
[22:48] <seb128> bregma, I can't reproduce that, alt-tab on the lock screen gives the focus back to the password entry for me
[22:48] <apw> yeah it doesn't reproduce immediatly for me, there must be some other factor, like self locking or something
[22:49] <seb128> self locking didn't do it for today
[22:49] <bregma> I can reproduce it by hitting alt-tab then without lifting tab, hit control-L
[22:49] <seb128> so maybe rather timing or bug or something
[22:49] <bregma> it's definitely a reproduceable bug, and I believe with a known solution
[22:50] <seb128> bregma, good to see you can reproduce, it means you can confirm the fix once we have one ;-)
[22:50] <seb128> good
[22:50] <seb128> I hope you guys plan to do a landing when that's available
[22:50] <apw> bregma, ok you are right if i ALT-tab and then without releasing ALT move to C-A-L to lock it does reproduce
[22:50] <bregma> the downside to the new screen locker is it raises a bunch of old stacking order problems, the upside is we already know how to solve most of those
[22:51] <seb128> that sentence would be better without the "most of"
[22:51] <seb128> when we though that being in the wm would make it easier to avoid stacking issues than being outside of it...
[22:53] <bschaefer> seb128, the stacking issue is that all nux windows are DOCK type, which according to the standard, FULLSCREEN windows stack above them
[22:53] <bschaefer> seb128, sooo the WM is doing the right thing, we just want a different behavior :)
[22:55] <xnox> apw: bregma i have a way to recover.
[22:55] <seb128> bschaefer, well, that doesn't explain alt-tab working in backend and other apps taking input while the lockscreen is displayed in front, does it?
[22:55] <bschaefer> seb128, well no, but i have a fix to hide the switcher before going into the lockscreen :)
[22:56] <seb128> xnox, recover what?
[22:56]  * bschaefer missed half of the convo
[22:56] <xnox> seb128: from broken lock.
[22:56] <seb128> xnox, <bregma> apw, here's trick to unlocking until the window ordering bug is fixed (and the fix is in the works): select an indicator, then select the password field again
[22:56] <xnox> seb128: meh, not fun =)
[22:56] <seb128> ;-)
[22:56] <xnox> seb128: i did: XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 dm-tool switch-to-greeter
[22:56] <xnox> and login again =)
[22:57] <seb128> bschaefer, so the issue is "only" that the switcher is open while the lockscreen kicks in?
[22:57] <seb128> xnox, haha
[22:57] <bschaefer> seb128, yup!
[22:57] <bschaefer> once you're in lockscreen you cannot use the switcher
[22:57]  * bschaefer double checks just to be sure :)
[22:57] <seb128> bschaefer, it's a bit weird, apw said it happen on a lock-on-idle for him
[22:57] <seb128> happened
[22:57] <seb128> like he was away from the box when it locked
[22:58] <seb128> so alt-tab was not likely open
[22:58] <bschaefer> seb128, i've actually never tested the lock-on-idle
[22:58] <seb128> that seems like something we should test ;-)
[22:58] <bschaefer> seb128, i can test that out, but ill get the fix for the switcher open when going into the lockscreen
[22:58] <seb128> we better release the lts with a secure lock screen
[22:58] <seb128> k
[22:58] <bschaefer> seb128, yeah i just now started using the lockscreen :)
[22:59] <seb128> let's see if some users still hit issues once those fixes land
[22:59] <bschaefer> cool, i have 4 other branches with some fixes as well landing
[22:59] <xnox> seb128: we only need secure lock screen in .1 ;-)
[22:59] <bschaefer> with the alt+tab
[22:59] <seb128> great, let's land that
[22:59] <seb128> xnox, hehe
[22:59] <seb128> on that note, calling it a day
[22:59] <seb128> night
[22:59] <bschaefer> seb128, have a good night!


[22:49] <ahasenack> 8h building? https://launchpad.net/~ahasenack/+archive/ubuntu/node-configurable-http-proxy/+build/23599410
[22:49]  * ahasenack doesn't believe it
[23:03] <blahdeblah> https://paste.debian.net/1239637/ I just saw this on my latest apt upgrade on my focal laptop.  Seems like a repeat of https://bugs.launchpad.net/lazr.restfulclient/+bug/1803558 in a slightly different context - anyone know if there was any effort made to track down other uses of that method?
[23:27] <sergiodj> ahasenack: I've had the same problem in a PPA.  just cancel and retrigger the build
[23:29] <ahasenack> I wanted to leave it like that for some troubleshooting tomorrow
[23:29] <ahasenack> but meh
[23:51] <ahasenack> sergiodj: that NO_PROXY trick for node-configurable-http-proxy wasn't enough for the Real Thing (launchpad)
[23:51] <ahasenack>     Unhandled promise rejection: RequestError: Error: getaddrinfo ENOTFOUND test.localhost.jovyan.org
[23:52] <ahasenack> I wanted to have tried a ppa before, but they were hosed that day
[23:52] <sergiodj> ahasenack: hm, interesting.  that looks like the error I was seeing locally
[23:52] <ahasenack> I will have to think of something else
[23:52] <ahasenack> since this is build time, I can't/shouldn't change /etc/hosts
[23:52] <sergiodj> I wonder if LP's DNS resolver also has DNS Rebinding protection active
[23:53] <ahasenack> maybe mdns, or change the test to use localhost