[00:00] <lifeless> well you might want to be sure that this happens before the probe
[00:00] <lifeless> for instance
[00:00] <lifeless> but I cam think of things that will make you cry
[00:00] <mwhudson> hm yes, that would be a bit backwards
[00:00] <mwhudson> lifeless: i think i've run out of tears in this area, but try me
[00:00] <lifeless> for instance, I can setup a bzr:// server serving a git branch over VFS only
[00:01] <lifeless> which will cause your local obejct to be a RemoteBzrBranch
[00:01] <mwhudson> ah true
[00:01] <lifeless> but the conversion to happen on your machine, not mine
[00:01] <lifeless> ditto svn
[00:02] <lifeless> so this is a little complex and worth thinking about some more.
[00:02] <lifeless> I think we should get rid of your new-process need in tests in the first instance.
[00:02] <lifeless> and fix the vfs/git after that, to get rid of the short term hack.
[00:02] <lifeless> for the 'deployed services need to be robust in xyz case' stuff we've been discussing, thats a longer term topic, right?
[00:03] <maxb> wgrant: No, I believe you. I'm adjusting lp-deps now.
[00:03] <wgrant> maxb: Thanks. Going to drop the slony deps while you're there?
[00:03] <mwhudson> lifeless: yes, sure
[00:04] <lifeless> ok
[00:04] <lifeless> well I'll volunteer to do the bzr-git change
[00:04] <lifeless> ifyou make a bug for it
[00:04] <wgrant> maxb: Please also depend on python2.5-egenix-mxtools.
[00:05] <wgrant> maxb: It contains the mx package.
[00:05] <mwhudson> lifeless: of course, using an open hook to limit the urls we access leads to a vaguely similar concern
[00:05] <mwhudson> as uninstalling hooks isn't support either, aiui
[00:06] <lifeless> mwhudson: hooks are reset by the test framework
[00:06] <mwhudson> ah ok
[00:06] <lifeless> you start in a new test with no hooks installed at all
[00:06] <lifeless> calling self.run_bzr installed the 'find command hooks'
[00:07] <lifeless> thats about it
[00:13] <wgrant> 2
[00:13] <wgrant> Gah.
[00:13] <mwhudson> lifeless: ok, i filed a few bugs, https://bugs.edge.launchpad.net/bzr-git/+bug/526133 is the bzr-git one
[00:13] <mup> Bug #526133: need to be able to unload bzr-git <Bazaar Git Plugin:New> <https://launchpad.net/bugs/526133>
[00:19] <poolie> kfogel: this is also true for the help homepage
[00:20] <maxb> wgrant: gah, oops. failed to see that and dputted already
[00:21] <kfogel> poolie: hmrm.  I wonder if there's a policy here, and if so, where it's documented.
[00:21] <wgrant> maxb: Nyeh. It's not really important.
[00:21] <wgrant> It'll just break in reasonably obscure ways if the PPA gets outdated again.
[00:21] <maxb> heh
[00:22] <maxb> it's annoying that 'import psycopg2' doesn't break
[00:22] <poolie> and you can't change that either, karl?
[00:23] <maxb> oh, yes it does, if you use the right version of python
[00:23] <wgrant> maxb: Yeah.
[00:23] <wgrant> maxb: Have you tried a full test run on Lucid?
[00:24] <wgrant> I've one running now, and there are a couple of the usual Soyuz failures.
[00:24] <wgrant> But otherwise it's looking good.
[00:24] <mwhudson> staging is down :(
[00:26] <mwhudson> and sysadmins are in europe
[00:26] <wgrant> mwhudson: It should be back in 15 minutes, no>?
[00:26] <wgrant> Maybe 10.
[00:26] <mwhudson> i've not caught it up yet today
[00:26] <mwhudson> admittedly i haven't tried all that hard
[00:26] <wgrant> I suspect it went for an update at 23:44Z
[00:27] <mwhudson> oh perhaps, i guess db-stable got updated around then
[00:28] <maxb> wgrant: I tried, and it was all hideous. I gave up and decided to lower my sights to python2.6 on karmic to start with
[00:28] <wgrant> I sort of wish it didn't pull.
[00:28] <maxb> Except then things broke more, and I spent some time fixing python2.5 on karmic. Got that branch landed today
[00:28] <wgrant> maxb: That bzr plugins thing?
[00:28] <maxb> ye
[00:28] <maxb> s
[00:29] <wgrant> Only one failure so far, and that's just extra hash type on apt-ftparchive output.
[00:29] <wgrant> So this is looking pretty good.
[00:30] <wgrant> Much better than Karmic was, at least.
[00:31] <wgrant> mwhudson: There aren't going to be any more recipe model changes, are there?
[00:31] <mwhudson> wgrant: not completely sure
[00:31] <mwhudson> wgrant: nothing fundamental aiui, apart from adding derived recipes
[00:32] <mwhudson> wgrant: there might be changes to do with multi-distroseries
[00:32] <mwhudson> yay staging is back
[00:32] <wgrant> Since the backend in trunk now works, it seems almost feasible to add API exports.
[00:32] <wgrant> mwhudson: Early!
[00:36] <maxb> wgrant: "so far" :-)
[00:36]  * mwhudson finds an old no-codeimportworker-db-access branch, merges 2000 revs of trunk into it
[00:39] <maxb> impressive
[00:39] <poolie> thumper: hi, quick call?
[00:40] <thumper> poolie: yeah, sure
[00:41]  * maxb waits for the publisher :-/
[00:43] <maxb> jelmer: Once the publisher gets around to it, the launchpad PPA should be fully installable on Lucid again
[00:43] <wgrant> maxb: I suppose you had to wait a cycle for the Lucid one to publish, then copy to other series, then wait for it to publish again?
[00:44] <maxb> no, I'm waiting for my second upload of lp-deps :-/
[00:44] <wgrant> Ah.
[00:44] <wgrant> I really should look at killing process-accepted.py for the normal case.
[00:44] <wgrant> Since it's only needed for binaries with custom uploads.
[00:45] <wgrant> Anything without custom uploads can be realised immediately on upload, allowing a copy as soon as it's built.
[00:45] <wgrant> We already skip it for sources.
[00:46] <maxb> btw, I have a fix locally for importfascist on py2.6, your testrun will probably run into it at some point
[00:46] <wgrant> maxb: I'm running it on 2.5, not 2.6 yet.
[00:47] <maxb> oh I see, the inverse to me, I tried 2.6/karmic
[00:47] <wgrant> I figure that we will need it running on Lucid in a month or so, so it probably deserves a full test run.
[00:48] <maxb> hrm, installing lp-deps has now started me a slony daemon :-/
[00:48] <wgrant> maxb: You saw the talk about that on the list?
[00:49] <maxb> yes - and: ah, no, it claimed it did, but it was lying to me
[00:49] <wgrant> Heh.
[00:55] <wgrant> mwhudson: There is a way to tell ec2test to take a standard Ubuntu AMI, Launchpadify it and run the test suite, isn't there?
[00:55] <mwhudson> wgrant: yess
[00:56] <mwhudson> wgrant: however the code in trunk assumes you can log in as root, not ubuntu
[00:56] <wgrant> I wondered if that was the case.
[00:56] <wgrant> But I'm sure I used it on a Karmic daily. Maybe I hacked it.
[00:57] <mwhudson> wgrant: lp:~mwhudson/launchpad/ec-log-in-as-ubuntu should work with a newer image
[00:57] <mwhudson> i should look at getting that merged i guess
[00:57] <wgrant> Probably.
[00:58] <wgrant> Official images are good.
[00:59]  * mwhudson writes it on a list
[01:53]  * thumper afk for a few minutes collecting the girls
[02:59] <thumper> anyone else not getting emails from EC2?
[02:59] <thumper> it seems that I'm not getting any
[03:00] <wgrant> I received a failure of my own a couple of days ago.
[03:00] <wgrant> I tried to ec2test something this morning, but the instance hung before it had finished booting.
[03:00] <thumper> mwhudson: launchpad-code has no New bugs :)
[03:00] <thumper> wgrant: :(
[03:00] <mwhudson> thumper: congrats
[03:01] <wgrant> (btw, the successor to the branch you tried to land yesterday landed over night)
[03:01] <mwhudson> thumper: i'm getting them
[03:01] <thumper> hmm
[03:01]  * thumper checks spam box
[03:04] <mwhudson> bugger
[03:05] <thumper> nope, not there
[03:06] <wgrant> thumper: So you're reproducibly not getting emails from it?
[03:06] <thumper> wgrant: haven't had an email from ec2 in several days
[03:07] <thumper> wgrant: can you send an email to me at tim.penhey@canonical.com?
[03:07] <thumper> wgrant: it could be being caught there
[03:07]  * thumper taps fingers
[03:07] <thumper> parent teacher interviews in 12 minutes
[03:07] <mwhudson> thumper: the incremental kernel import failed :( https://code.staging.launchpad.net/~kiko/linux/2.6.31
[03:09] <thumper> mwhudson: just saw the email
[03:09] <thumper> mwhudson: perhaps ordering on the revisions it is choosing to import?
[03:09] <wgrant> thumper: Sent.
[03:09] <thumper> mwhudson: just a wild arse guess
[03:09] <thumper> wgrant: ta
[03:09] <thumper> wgrant: the email from mwhudson was addressed to that too and arrived fine
[03:10] <mwhudson> thumper: well, the import list we're slicing into is topo sorted, so that shouldn't be a problem
[03:10] <thumper> wgrant: got your email :(
[03:10] <thumper> wgrant: so it isn't that
[03:10] <thumper> it seems ec2 hates me
[03:10]  * thumper stopping for a few hours,
[03:10] <thumper> back later
[03:11] <mwhudson> thumper: i guess run ec2 non-headless with --postmortem and log in and poke around after the tests are done
[04:28] <mwhudson> gararar i'd forgotten how annoying working with the internal xmlrpc server was
[04:29]  * mwhudson EODs
[04:29]  * wgrant has never had the pleasure.
[04:30] <mwhudson> the main reason it sucks is that requests are not authenticated
[04:30] <mwhudson> so either you have to weaken permissions or use removeSecurityProxy all over
[04:30] <mwhudson> oh and faults are a crummy way to report errors
[04:30] <wgrant> Oh, nice.
[04:31] <wgrant> Yeah, I know that much from buildd work.
[04:31] <mwhudson> i should look (again) at using the PermissiveSecurityPolicy for xmlrpc server requests i guess...
[04:31] <wgrant> That seems like a really good idea.
[04:33] <mwhudson> oh guess what
[04:33] <mwhudson> the security policy is global, not per-request
[04:33] <mwhudson> i think
[04:35] <wgrant> Ah ha ha.
[04:36] <mwhudson> mmmmmmmmm
[04:36] <mwhudson> maybe not actually
[04:37] <mwhudson> aaaa
[04:37]  * mwhudson stares into the zope vortex
[04:38] <wgrant> Nooooooooo.
[04:39]  * wgrant throws xx-resetpassword-of-sso-account.txt out the window.
[04:46] <mwhudson> well, that seems to not be really true
[04:46] <mwhudson> but still overriding the policy per request does seem quite hard
[06:48] <wgrant> Is update-sourcecode broken for anyone else? It can't find bzrlib.branch.
[06:49] <wgrant> Ah, probably because it's running with 2.5, and it's meant to use the system's bzr.
[06:53] <jelmer> mwhudson: ping
[06:56] <lifeless> wgrant: system bzr should be installed for all python versions
[06:57] <wgrant> lifeless: Yes, and Python 2.5 doesn't exist.
[06:58] <wgrant> Lucid hates it and wants it to die.
[06:58] <wgrant> Odd that it's only broken recently, though.
[08:24] <adeuring> good morning
[09:08] <wgrant> bigjools: Thanks for getting that landed.
[09:59] <bigjools> wgrant: np
[10:03] <wgrant> bigjools: Has somebody poked you about the eaten binary?
[10:03] <bigjools> umm no
[10:04] <wgrant> bigjools: create-resources in lucid was eaten today by the arch-indep reverted override bug.
[10:04] <wgrant> It wants to be revived.
[10:05] <bigjools> which bug is that?
[10:06] <wgrant> If you take an arch-indep binary, override it, then override it back within one publishing cycle, it gets eaten.
[10:06] <bigjools> oh that
[10:06] <wgrant> It's very difficult to fix, so it hasn't been yet.
[10:06] <wgrant> (I think somebody should just fix change-override.py to die if it's going to get into that situation, really)
[10:07] <bigjools> we could record overrides as an intermediate step and refuse further overrides
[10:07] <wgrant> We could either reject further conflicting overrides, or just mutate the existing Pending publishing record.
[10:08] <wgrant> Although I don't trust the publisher to be sufficiently respectful that that would be safe.
[10:09] <bigjools> it needs time for analysis and given the frequency of occurrence it's not exactly a priority for us, unfortunately
[10:10] <wgrant> Indeed.
[10:10] <bigjools> I am deep in a refactor for process-accepted
[10:10] <bigjools> converting it to a LaunchpadScript sounded a good idea at the time
[10:10] <wgrant> Ah.
[10:10] <wgrant> I didn't think it was otherwise much work.
[10:10] <wgrant> Are you going with per-copy-archive selection, or just all copy archives?
[10:10] <bigjools> it should not be but I seem to be suffering from pebcak
[10:10] <bigjools> all
[10:11] <wgrant> OK. So it was about a four line change :P
[10:11] <bigjools> yes, it should have been ....
[10:11] <bigjools> but see if you can find any existing tests that I can add a 4 line change to
[10:11] <bigjools> the testing is shambolic
[10:11] <bigjools> which is why I am refactoring
[10:11] <wgrant> Ha ha ha.
[10:12] <bigjools> it'll make testing easier
[10:12] <bigjools> Popen on a script is not a test, it's a sledgehammer
[10:14] <wgrant> I'd like to discuss PPA download stats at some point when you're free. I got something reasonably working and tested over the weekend.
[10:14] <bigjools> oh awesome
[10:14] <wgrant> Only for binaries, since it is completely unclear how index counts will work.
[10:16] <bigjools> ok let me finish this code first
[10:16] <wgrant> Certainly.
[11:00] <deryck> Morning, everyone.
[11:08] <bigjools> howdy deryck
[11:27] <adeuring> what happened to the bug heat icons? I don't see anything about bug heat in trunk or in db-devel...
[11:30] <wgrant> adeuring: It looks quite present in both to me.
[11:30] <deryck> adeuring, what do you mean?  You can't find how the icons are used in code?  or on LP itself?
[11:30] <adeuring> deryck: no, I don't see anything in the browser....
[11:31] <adeuring> Or am I looking at the wrong pages?
[11:31] <intellectronica> adeuring: maybe that's the same problem joey had the other day, with icons not displaying?
[11:31] <adeuring> like bugs.launchpad.dev/ubuntu
[11:31] <adeuring> intellectronica: may be, I don't know about joey's problem...
[11:31] <wgrant> The hot bugs list doesn't show them.
[11:31] <wgrant> Normal bug listings and bug pages do, though.
[11:32]  * adeuring is completely confused...
[11:32] <intellectronica> adeuring: try any normal bug listing, they should be there
[11:32] <deryck> adeuring, yeah, the actual hot bugs list doesn't have them.  I think it should, though we've had some disagreement about this.
[11:32] <deryck> intellectronica, what do you think about this ^^?  i.e. adding them to the hot bugs list?
[11:33] <intellectronica> deryck: the problem is that for any project with a reasonable amount of bugs, all the bugs on the hot bugs list will show four flames
[11:33] <intellectronica> and with no new information, shame about the space
[11:33] <intellectronica> then again, there's an argument from consistency
[11:33] <wgrant> Does the hot bugs lists have a purpose?
[11:33] <adeuring> consufison reolved...
[11:34] <deryck> intellectronica, yeah, I agree with the problem statement.  But it is a confusing UI, since they appear everywhere else.
[11:34] <deryck> wgrant, show the 10 hottest bugs.
[11:34] <wgrant> deryck: Why?
[11:34] <wgrant> deryck: What does that achieve that showing +bugs ordered by hotness doesn't?
[11:35] <wgrant> Apart from requiring an extra page load to get more than 10 bugs.
[11:35] <deryck> wgrant, as an "overview" bugs page it shows you an overview of the hottest bugs.
[11:35] <intellectronica> wgrant: i think it's only really useful for users who aren't heavily involved in the project they're viewing. i almost never look at this list.
[11:35] <deryck> wgrant, everything on that page is a link to something else, no?
[11:37] <wgrant> deryck: How is https://bugs.edge.launchpad.net/ubuntu more useful than https://bugs.edge.launchpad.net/ubuntu/+bugs?orderby=-heat?
[11:38] <deryck> wgrant, I'm not arguing it is. :-)  But in "theory" there is room for more info on the top-level page, should we want to add it.  i.e. a "Recent books" top 10, etc.
[11:39] <wgrant> deryck: Possibly.
[11:39] <wgrant> But this suffers from the same problem as lots of other features.
[11:39] <wgrant> it gets added in a completely useless fashion.
[11:39] <wgrant> Angers users.
[11:39] <wgrant> And then maybe eventually gets fixed a year later.
[11:39] <wgrant> (see also bug heat)
[11:40] <deryck> wgrant, first, I don't get the sense anyone is angry about this or that it's useless.  And second, we're not done, and I assure you, we won't leave this work until people are happy.  Can we make *every* Ubuntu dev or LP user happy?  No.
[11:40] <intellectronica> wgrant: one way in which it is more useful is that it renders faster
[11:40] <wgrant> intellectronica: I considered that.
[11:41] <wgrant> deryck: It irritates everybody on my team.
[11:41] <wgrant> because it means an extra click to get where they want to go.
[11:41] <intellectronica> wgrant: i find it surprising that people on your team even go to that page. i never do, and i was under the impression that most serious users don't.
[11:41] <wgrant> A feature looks a lot less bad if it's deployed fantastic rather than useless and fixed gradually later.
[11:42] <wgrant> intellectronica: The Bugs tab and breadcrumb go there.
[11:42] <deryck> wgrant, and we're trying to fix this.  BjornT is working on a solution to make this possible.  Right now, with monthly releases and incremental work in small branches, it's actually hard to do this.
[11:42] <intellectronica> wgrant: we're actually moving towards doing more work separated from edge before landing a feature
[11:43] <wgrant> That would be very good.
[11:44] <wgrant> Bug heat had the potential to be a pretty exciting feature. But it was rolled out too early, and is now just a set of four gray unexplained flames wasting space. Even when it becomes awesome later, it will not have the same effect.
[11:45] <deryck> wgrant, will have the effect of "wow, bug heat!"  No.  Will it be a nice, useful feature?  yes.  So what's the harm?
[11:45] <deryck> wgrant, (I'm being a bit sarcastic to make my point.  I agree we could do better at this.  But I think you're being a bit hyperbolic and unfair about he harm here.)
[11:45] <intellectronica> wgrant: to some extent there's agreement about that, which is why a lot of effort is being put now into providing the infrastructure for working like that, but i also have a lot to say in favour of working in the open, and letting features evolve with input from users
[11:45] <deryck> s/he harm/the harm/
[11:46] <wgrant> intellectronica: Deploying it to edge is fine and great for that.
[11:47] <wgrant> deryck: Quite a few people really don't like Launchpad very much.
[11:47] <wgrant> Impressions like that do matter, sadly.
[11:47] <intellectronica> quite a few people don't like coffee too
[11:48] <deryck> wgrant, I agree we could make a better impression.  We're trying to fix this.
[11:51] <wgrant> So, I've just had a look at MergeWorkflowDraft. And it indeed looks like a much more flexible setup.
[14:14] <james_w> is it intentional for a single file in lazr.enum to be LGPL with (or later), when the rest of lazr seems to just be LGPL?
[14:17] <kfogel> james_w: seems unlikely to be intentional, unless that file has special provenance...
[14:17] <james_w> http://bazaar.launchpad.net/~lazr-developers/lazr.enum/trunk/annotate/head:/src/lazr/enum/_enum.py
[14:18] <james_w> no other declared copyright holders and no statement of code taken from elsewhere
[14:25] <kfogel> james_w: looks completely like an accident to me.  Check with barry maybe?
[14:25] <james_w> it looks like leonardr started lazr.enum
[14:25] <kfogel> james_w: oh, maybe leonardr would be better
[14:25] <leonardr> james_w: i'm looking
[14:26] <leonardr> james_w: i believe that code was refactored out of launchpad
[14:27] <wgrant> jtv: Shouldn't start-soyuz.sh be Makefile targets, and the result of make-ubuntu-sane.py be added to the dev sampledata?
[14:28] <jtv> hi wgrant!  The latter is exactly what I'm looking at now.
[14:28] <jtv> The big question is how many tests it'll break.
[14:28] <adiroiban> sinzui: hi. do you remember the form next_url bug when you suggest using HTTP_REFERER ? The is a problem when the form is changing the object name and so the URL is changed. I have this code but I am not happy with it http://paste.ubuntu.com/382280/ ?
[14:28] <leonardr> kfogel: flacoste is the final authority but i think that's just an oversight and it can be changed
[14:28] <wgrant> None, because they don't use the dev sampledata.
[14:29] <sinzui> hmm
[14:29] <wgrant> They use the other sampledata.
[14:29] <adiroiban> do you know a better solution?
[14:29] <jtv> wgrant: gah!  Of course.
[14:29] <leonardr> kfogel: see the README. it still says "Enumerated types are used primarily in two distinct places in the Launchpad code"
[14:29]  * sinzui looks
[14:29] <jtv> wgrant: my brain doesn't seem to be working this week
[14:29] <flacoste> kfogel, leonardr, james_w: it's an error, everything should be LGPLv3 only (no or later)
[14:30] <kfogel> flacoste: thx
[14:30] <wgrant> jtv: I've not been maintaining the script since I don't use the sampledata any more.
[14:30] <jtv> wgrant: why is that?
[14:30] <kfogel> james_w: feel free to fix up the README as leonardr points out too :-).
[14:30] <sinzui> adiroiban: take a look at .lp.registry.browser.product.ProductReviewLicenseView.next_url
[14:30] <wgrant> jtv: Too much bad idea in Ubuntu.
[14:30] <jtv> wgrant: EPARSE
[14:30] <james_w> kfogel: I wasn't planning to fix the license statement :-)
[14:31] <wgrant> jtv: bad data
[14:31] <jtv> wgrant: so what do you use?  Just dogfood?
[14:32] <adiroiban> sinzui: but you can not change the product name from ProductReviewLicenseView
[14:32] <adiroiban> so the form action is not causing any URL change
[14:32] <sinzui> adiroiban: sorry, I misunderstood your issue
[14:32] <wgrant> jtv: I have a similar script which uses the factory to populate an empty DB with celebrities and Ubuntu stuff.
[14:34] <sinzui> adiroiban: yes, that is not pretty code, but at a glance, it looks correct.
[14:34] <adiroiban> sinzui: yes. is is ugly. the correct one is here http://paste.ubuntu.com/382283/
[14:35] <adiroiban> sinzui: I can not think at a prettier solution
[14:35] <adiroiban> :(
[14:36] <jtv> wgrant: that sounds interesting... though I don't want to get into a full-scale sample data rewrite, of course.  :)
[14:36] <wgrant> jtv: No. That sounds messy.
[14:37] <wgrant> I think you should be able to get away with just running that script and making newsampledata.
[14:37] <sinzui> adiroiban: there is an old bug in launchpad-foundations about broken next_urls  caused by a rename. Launchpad does not handle the situation well in some circumstances. Most engineers never experience the problem because most objects cannot be renamed.
[14:37] <jtv> wgrant: yes, that's what I was thinking too.
[14:38] <wgrant> Although deleting all the primary publications probably isn't advisable, since it will break other parts of LP.
[14:38] <wgrant> (eg. bug filing on packages)
[14:40] <adiroiban> sinzui: hm... is this bug 34228 ?
[14:40] <mup> Bug #34228: Implement a "teleportation" or "jump-to" feature <feature> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/34228>
[14:40] <jtv> wgrant: it's really only just a status change, isn't it?
[14:41] <wgrant> jtv: Yes, but that might be sufficient to break things.
[14:42] <jtv> wgrant: I'd prefer to delete the old ones and set up some new, entirely up-to-date ones.
[14:42] <wgrant> And it will certainly be sufficient to render parts of the UI not easily testable.
[14:42] <jtv> The catch is, I have no idea what's required.
[14:42] <wgrant> So, the reason I delete them is that they reference librarian files without data.
[14:43] <jtv> wgrant: can we provide those?
[14:43] <wgrant> jtv: I suppose so.
[14:44] <wgrant> That would let us have a reasonable set of default publications for the UI, and also be able to actually publish the archive if required.
[14:44] <bigjools> one day, death to sampledata apart from major celebs
[14:44] <sinzui> adiroiban: no, the one am thinking of contains a step by step scenario of changing a person or product name and the user gets a 404.
[14:45] <wgrant> bigjools: I've already declared death to sampledata except for the bits of my script that I elect to run... it works pretty well.
[14:45] <adiroiban> sinzui: i tried searching launchpad-foundations after „rename” or „next_url” ... but no luch
[14:45] <adiroiban> luck
[14:45] <wgrant> No 5-year-old impossibly broken objects!
[14:45] <bigjools> heh
[14:46] <bigjools> some of the original sample data is.... special
[14:52] <jtv> wgrant: so... what would we need to provide?
[14:53] <wgrant> jtv: A tarball of the library files for the published sources and binaries.
[14:54] <deryck> adeuring, there are some issues with your icon branch, I believe.  hold on submitting to ec2 til I check something.
[14:54] <wgrant> But it may just be easier to tell people to delete everything if they want to do anything Soyuzy.
[14:54] <adeuring> deryck: ok. What are the problems?
[14:54] <jtv> wgrant: I'm such a non-Soyuz person that what you just said doesn't mean much to me.
[14:54] <deryck> adeuring, there were new color icons as well and the icons were prepared to use a single image for each degree of heat.
[14:55] <deryck> adeuring, and these should be done via sprites, too.
[14:55] <adeuring> deryck: Ah, i see.
[14:55] <wgrant> jtv: So, publish-distro.py will whine and crash if there are published packages for which the corresponding librarian files are missing.
[14:55] <deryck> adeuring, I'll update the MP with comments and info.  Sorry to not have caught you earlier about these.
[14:56] <adeuring> I thought that the five images were just another way to show how things should look
[14:56] <jtv> wgrant: what needs to be in those files?
[14:56] <deryck> adeuring, no, those are actually the images to use.
[14:56] <adeuring> ok
[14:56] <wgrant> jtv: Source and binary packages.
[14:57] <jtv> wgrant: how painful would it be to get those into the Librarian out of the box?
[14:58] <wgrant> jtv: Out of the box sounds branch-bloating. But providing a tarball that can be extracted into /var/tmp/fatsam for interested would be easy enough.
[14:59] <jtv> wgrant: true
[15:00] <jtv> wgrant: but is that better than having make-ubuntu-sane.py in utilities?
[15:00] <wgrant> jtv: I do not know.
[15:00] <wgrant> One-size-fits-all sample data cannot really work.
[15:02] <deryck> adeuring, MP is updated now.  Sorry to send you back to work. :-)
[15:02] <adeuring> np
[15:02] <jtv> wgrant: I was hoping it might, but I don't want to make it the goal of the month either.  :)
[15:03]  * wgrant mumbles something about 2am, and sleeps.
[15:03] <jtv> wgrant: I was wondering about that...  in fact that's why I didn't ask you about it today  :)
[15:03] <wgrant> Heh.
[15:03] <jtv> good night, and thanks.  :)
[15:04] <wgrant> np
[15:17] <deryck> adeuring, so the alt and title attributes are required for heat icons and you note.  Sorry for my mistake...
[15:17] <deryck> adeuring, alt can be something like "3 out of 4 heat flames" I think.  I'm open to better suggestions there.
[15:18] <deryck> adeuring, and the title attribute is bug 513219
[15:18] <mup> Bug #513219: flames have no tooltip <story-bug-heat> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/513219>
[15:18] <adeuring> deryck: OK, that works. But I though it would make sense to use something "super hot bug", "very hot bug" etc
[15:18] <deryck> adeuring, yeah, that works well too.
[15:18] <deryck> adeuring, and you could fix bug 513219 the same time as this one. :-)
[15:19] <mup> Bug #513219: flames have no tooltip <story-bug-heat> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/513219>
[15:19] <adeuring> deryck: yure. But again, any suggestion what to display tehre ;)?
[15:19] <deryck> adeuring, I think this could be the heat number itself for now.  Something like: "Heat: 420"
[15:20] <adeuring> deryck: thnkas, that's a nice idea!
[15:20] <deryck> adeuring, when I finish my branch, we can include the context max_heat, so "Heat: 420 out of 10,000"
[15:20] <adeuring> ok
[15:21] <deryck> adeuring, I think the tooltip could include "base on X subscribers, X dupes, X affected users" (or something similar)  But I worry that gets noisy.
[15:21] <deryck> s/base/based
[15:21] <adeuring> deryck: yeah, let's keep it simple ;)
[15:22] <deryck> adeuring, agreed :-)
[15:22] <deryck> some have asked for this, though.
[15:57] <kfogel> adeuring: ready.  You might want to have my branch at hand (lp:~kfogel/launchpad/515584-use-zope-form) while we're talking.
[15:59]  * adeuring is pulling the branch-...
[16:01] <adeuring> kfogel: shall i call you?
[16:01] <kfogel> adeuring: sure.  skype?
[16:01] <adeuring> kfogel: yes
[16:02] <kfogel> adeuring: lib/lp/bugs/browser/bugtarget.py
[16:02] <kfogel> adeuring: class BugsPatchesSortFormView(LaunchpadFormView):
[16:02] <kfogel> """Browser view class for sorting bugtasks with patch attachments."""
[16:03] <kfogel> lib/canonical/launchpad/webapp/launchpadform.py
[16:13] <kfogel> intellectronica: ayt?
[16:13] <intellectronica> kfogel: what does ayt mean?
[16:13] <intellectronica> and in what language?
[16:13] <intellectronica> are you there?
[16:14] <kfogel> intellectronica: "are you there", yes.  And the real question is: do you have time for a quick call about lp:~kfogel/launchpad/515584-use-zope-form? :-)
[16:14] <intellectronica> kfogel: sure
[16:14] <intellectronica> kfogel: give me 5 minutes, though, to get skype going
[16:14] <kfogel> intellectronica: sure, ping me when ready
[16:18] <intellectronica> kfogel: ready when you are
[16:18] <kfogel> intellectronica: ok, one sec to gt headphones on
[16:19] <kfogel> intellectronica: dailing you
[16:20] <kfogel> lp:~kfogel/launchpad/515584-use-zope-form
[16:22] <kfogel> http://paste.ubuntu.com/382345/
[16:23] <kfogel> intellectronica: search for this in the file: def patchTaskOrderings(self)
[16:23] <kfogel> lib/lp/bugs/templates/bugtarget-patches.pt
[16:27] <kfogel> lib/lp/answers/interfaces/faqcollection.py:class FAQSort(EnumeratedType):
[16:46] <kfogel> intellectronica: I'm looking in the code for an example of a form that works the way you described.  If I grep for "(EnumeratedType" there are about 20 hits throughout the code (http://paste.ubuntu.com/382372/).  But I don't see new variables being created with those enumerated types.  Instead, the enum classes (or values in them) are used directly.  For example, in class IBranchListingFilter, see this line:
[16:46] <kfogel>     sort_by = Choice(
[16:46] <kfogel>         title=_('ordered by'), vocabulary=BranchListingSort,
[16:46] <kfogel>         default=BranchListingSort.LIFECYCLE)
[16:46] <kfogel> intellectronica: "BranchListingSort" is a class that inherits from EnumeratedType.
[16:47] <intellectronica> kfogel: yes, that's the way it's used
[16:47] <kfogel> intellectronica: ok
[16:47] <intellectronica> kfogel: EnumeratedType isa zope vocabulary
[16:47] <kfogel> intellectronica: *nod*
[16:56] <kfogel> okay, intellectronica -- please sanity check my writeup here (I mainly want to make sure that the example I chose is a textbook example of what we were talking about): http://paste.ubuntu.com/382378/
[16:58] <intellectronica> kfogel: yes, that's perfect
[16:58] <kfogel> intellectronica: thanks!
[17:12] <kfogel> deryck: ping for 5-10 min phone chat when you have a chance
[17:13] <kfogel> re 515584 and some general prioritization questions
[17:13] <deryck> kfogel, ok.  Give me 5 minutes to get to stopping point, if that's cool.
[17:15] <kfogel> deryck: yup
[17:22] <abentley> wgrant, around?
[17:24] <deryck> kfogel, I can chat now if you like.  Skype?  Phone?
[17:25] <kfogel> deryck: +1 (347) 591-7738
[17:25] <deryck> kfogel, ok, calling now.
[17:25] <kfogel> deryck: no you're not.  you're typing :-)
[17:26] <deryck> one handed
[17:26] <kfogel> wow
[17:26] <kfogel> https://bugs.edge.launchpad.net/malone/+bug/515584
[17:26] <mup> Bug #515584: BugsPatchesView:batchedPatchTasks() should use a Zope form, instead of validating form values manually <story-patch-report> <Launchpad Bugs:In Progress by kfogel> <https://launchpad.net/bugs/515584>
[17:26] <kfogel> https://bugs.edge.launchpad.net/malone/+bug/322130
[17:26] <mup> Bug #322130: Convert IHasBugs.searchTask(order_by) to use a real enumeration <api> <tech-debt> <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/322130>
[17:34] <thekorn> ^ ha! - it would be great if the last one could be fixed ;)
[18:03] <kfogel> intellectronica: can I submit lp:~kfogel/launchpad/515584-fix-DRY-violation to you for review?  Note it has a very trivial UI effect -- the sort orderings have better names now -- so I'd list you as the UI reviewer too, though I'm not even sure it needs UI reviw.
[18:07] <intellectronica> kfogel: i'm just on my way out, so it's probably better if you try and find someone else. if you don't, submit it to me anyway and i'll review it when i'm back later in the evening
[18:07] <kfogel> intellectronica: np, thanxs
[18:07] <kfogel> gmb: mind if I submit lp:~kfogel/launchpad/515584-fix-DRY-violation to you for review?  Small change.
[18:59] <bac> hi abentley.  i want to lp-land a branch for someone else.  if i use 'bzr lp-land <url-of-MP>' will it work, even if i don't have a local copy of the branch or a copy on LP?  should it just get all of that info from the MP?
[19:00] <abentley> bac, I haven't tried it yet, so I think it would fail.
[19:00] <bac> abentley: indeed it does, but with a bzr error
[19:00] <bac> it would be handy if it worked
[19:01] <abentley> bac, I agree.
[19:06] <bac> abentley: i'm getting: bzr: ERROR: exceptions.AttributeError: 'Entry' object has no attribute 'source_branch'
[19:08] <abentley> bac, that sounds pretty desperate.  source_branch would be on the merge proposal.  What's the traceback?
[19:16] <bac> abentley: i got no traceback but have a crash report
[19:17] <bac> which i haven't looked at yet
[19:17] <abentley> bac, rerun with -Derror.
[19:17] <bac> ok
[19:18] <bac> abentley: still no traceback
[19:19] <bac> ah, it's in the crash report
[19:19] <bac> abentley: http://paste.ubuntu.com/382450/
[19:20] <abentley> bac, that's very strange-- the object that's supposed to be a merge proposal has no source branch.
[19:20] <bac> abentley: OOPS -- i pasted in the URL to the branch not the MP!
[19:22] <bac> abentley: by that i mean, in the lp-land command i'd inadvertantly used the URL of the branch not the URL of the MP
[19:22] <abentley> bac, right, I'd forgotten about that option.
[19:23] <abentley> bac, we should probably add a -d option to specify the branch.
[20:52] <mwhudson> jelmer: hi?
[20:52] <mwhudson> argh argh argh git isn't installed on any data centre machiens
[20:52] <jelmer> mwhudson, hello
[20:52] <mwhudson> jelmer: you can probably guess what i want to talk about
[20:57]  * mwhudson fires up an ec2 instance to test stuff on
[20:58] <mwhudson> jelmer: :(
[20:59] <jelmer> mwhudson: Cricket? ;-)
[20:59] <mwhudson> heh
[20:59] <mwhudson> no
[21:00] <jelmer> mwhudson: I saw the URL you pasted. My guess is that we are somehow updating the git map before we've added the revisions to bzr
[21:01] <mwhudson> jelmer: oh, so the git map contains all the objects in the git repo, but we only imported some of them
[21:01] <mwhudson> jelmer: oh, something else that might have happened
[21:01] <mwhudson> we imported 1000 revisions
[21:01] <jelmer> mwhudson, I'm just speculating
[21:01] <mwhudson> but the branch only contains 930
[21:01] <jelmer> but that's what I would guess based on the error
[21:01] <jelmer> mwhudson, oh
[21:01] <jelmer> mwhudson, that would explain it as well
[21:02] <mwhudson> presumably because not all of the imported revisions are in the ancestry of the last one we imported
[21:02] <jelmer> perhaps we imported those revisions but they didn't up in the repo for some reason?
[21:02] <mwhudson> well, sure
[21:02] <mwhudson> we only move the branch around between import attemps with 'push'
[21:02] <jelmer> mwhudson, does the repo contain 1k revisions even if the branch doesn't?
[21:02] <mwhudson> i doubt it
[21:03] <mwhudson> i can't access the repo directly in any case
[21:03] <mwhudson> ENOLOSA
[21:04] <mwhudson> jelmer: A way to fix this, though perhaps not a totally sensible one
[21:06] <mwhudson> is to, in import_git_objects, compute revision_ids as now, then take revision_ids[limit] as the new desired head and recompute revision_ids
[21:06] <mwhudson> alternatively, we can try harder to preserve all revisions in the repo between import attempts
[21:08] <lifeless> rockstar: what are you looking at ?
[21:09] <mwhudson> jelmer: thanks for the hint at least!
[21:13] <mwhudson> bah
[21:13] <poolie> hello mwhudson, lifeless, jelmer
[21:13] <lifeless> mwhudson: this is incremental fetching?
[21:14] <mwhudson> lifeless: yar
[21:14] <lifeless> mwhudson: you can use targetb.repository.fetch(sourceb.repository)
[21:14] <lifeless> mwhudson: that will copy all heads
[21:14] <mwhudson> lifeless: oh that transfer all revs?
[21:14] <lifeless> not just referenced ones
[21:14] <mwhudson> lifeless: iinteresting
[21:14] <lifeless> just call that after branch.push
[21:15] <mwhudson> sweet
[21:15] <lifeless> hi poolie
[21:15] <mwhudson> and pull i guess?
[21:15] <mwhudson> or sprout, in this case, i think
[21:20] <mwhudson> lifeless: what does BzrDir.sprout return? is it the branch?
[21:22]  * mwhudson must try not to fix every oddness in one go
[21:23] <lifeless> mwhudson: yes and pull
[21:23] <lifeless> sprout returns the new bzr as per its docstring
[21:24] <lifeless> I'm pretty sure [without checking code, that is]
[21:24] <mwhudson> lifeless: the docstring is not super clear about this
[21:24] <lifeless> mwhudson: if this works around it for you, file a bug on bzr-git, you shouldn't need to do this, and other folk doing imports may run into it
[21:24] <mwhudson> (i did read it first)
[21:24] <lifeless> mwhudson: ok; let me check then
[21:24] <mwhudson> lifeless: um, noone else will be using the bzr-git feature for this
[21:25] <mwhudson> (as i wrote it last week)
[21:25] <mwhudson> and there's no command line interface
[21:25] <lifeless> it returns the new bzrdir
[21:25] <lifeless> bzrdir.sprout, that is
[21:25] <mwhudson> cool, that makes sense
[21:25] <mwhudson> yeah
[21:28] <thumper> Ursinha-food: ping
[21:28] <Ursinha-food> thumper: pong
[21:28] <thumper> Ursinha-food: http://dev.launchpad.net/CodeTeamTestPlans/10.02?action=diff&amp;rev1=39&amp;rev2=40
[21:29] <mwhudson> thumper: should be able to fix incremental imports easily enough \o/
[21:29] <thumper> Ursinha: just got a whole heap of old commits added to the test plan
[21:29] <thumper> mwhudson: awesome
[21:29] <Ursinha> argh
[21:29] <Ursinha> *sigh*
[21:30] <Ursinha> thanks thumper
[21:30] <thumper> Ursinha: np
[21:31] <Ursinha> thumper: this is because I've implemented the changes to add only edge/staging items to the testplans but the files that contain the last revision numbers were overwritten
[21:31] <thumper> oops
[21:45] <rockstar> lifeless, I'm not sure what you mean.
[21:46] <thumper> rockstar: are you back?
[21:46] <rockstar> thumper, I am.
[21:46] <thumper> rockstar: talk now?
[21:46] <rockstar> thumper, 5 minutes?  My car is running in the driveway right now, and I need it to run just a little longer before I shut it off.
[21:46] <thumper> ok
[21:54] <mwhudson> gosh launchpad takes a long time to import
[21:56] <thumper> mwhudson: from what?
[21:56] <thumper> rockstar: I have a call with flacoste in 5 minutes
[21:56] <mwhudson> thumper: just the time between starting ./bin/test and tests actually start running
[21:56] <mwhudson> it'
[21:56] <mwhudson> it
[21:57] <thumper> ah
[21:57] <mwhudson> it's like 4 seconds
[21:57] <mwhudson> and the test i'm running takes 0.1...
[21:59] <rockstar> thumper, okay, I'll grab you afterwards.
[22:00] <thumper> rockstar: take a look at the code first then :)
[22:00] <rockstar> thumper, doing that now.
[22:00] <thumper> flacoste: ready?
[22:00] <flacoste> thumper: yep
[22:07] <thumper> abentley: is there an RT for the staging email issue?
[22:08] <abentley> thumper, yes, but I don't know the number.  Chex said he had an open ticket.
[22:12] <flacoste> abentley, thumper: RT #37601
[22:12] <mup> Bug #37601: unable to burn dvd .iso <gnomebaker (Ubuntu):Fix Released by motu> <https://launchpad.net/bugs/37601>
[22:29] <kfogel> intellectronica: thanks.  incorporating your suggestions and resubmitting for review in a bit
[22:29] <intellectronica> cool
[22:39] <maxb> I wish the testsuite logged somewhere useful from its background components :-(
[22:40] <maxb> wgrant: Reckon we should start a lucid status wiki page?
[22:54] <wgrant> maxb: I was thinking that last night, but there are only three tests plus one or two utilities.
[22:55] <wgrant> (plus that bootstrapping setuptools/distribute issue which only sometimes shows up)
[22:57] <wgrant> (question-target.txt, test_ftparchive, and update-sourcecode are the problems I know of)
[23:34] <wgrant> maxb: Did you dsee that xx-resetpassword-of-sso-account.txt is gone?
[23:37]  * mwhudson lunches
[23:46] <wgrant> I can't create a user any more, can I?
[23:46] <lifeless> wgrant: why not?
[23:47]  * wgrant sighs at offloading of functionality to external proprietary applications.
[23:47] <wgrant> lifeless: LP uses OpenID now, so I can't create new users locally for testing.
[23:47]  * wgrant gets out the factory.
[23:47] <lifeless> wgrant: so, you should setup an authorising party, and point your test lp at it for auth :>
[23:48] <wgrant> lifeless: It's producer-locked, sadly.
[23:48] <wgrant> And the test producer doesn't have functionality to create a user.
[23:48] <lifeless> yes, but you can change that :)
[23:48] <wgrant> That functionality is reserved for that quaity piece of software that is c-i-p.
[23:49] <abentley> wgrant, launchpad does not yet use OpenID AFAIK.
[23:49] <lifeless> even in your local, test lp ?
[23:49] <wgrant> abentley: As of 7 hours ago it does. Which is good.
[23:51] <abentley> wgrant, in stable or db-stable?
[23:51] <wgrant> abentley: devel. Might not be in stable yet.