[00:26] <wallyworld> https://code.edge.launchpad.net/~wallyworld/launchpad/reassign-reviewer-cancel-option/+merge/36671
[00:26] <wallyworld> StevenK: ^^^^^^^^^^^^
[00:26] <wallyworld> thanks ;-)
[02:46] <poolie> can someone review https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/35877
[02:46] <poolie> it's a big performance improvement
[03:28] <wallyworld> StevenK: ping?
[08:13] <henninge> noodles775: just one little thing: I don't think putting an all-caps CURRENT and ALWAYS in test names names is the right thing to do. I'd just keep the names low key ... ;)
[08:14] <henninge> s/names names/method names/
[08:16] <noodles775> henninge: as in test_blacklist_options_initial_values_CURRENT ? Right - I initiall was reflecting the enum. I've sent that branch to land, but will updated it in the next.
[08:16] <noodles775> s/initiall/initially
[08:16] <henninge> noodles775: that's fine, it's not a big deal.
[11:09] <allenap> gmb: Can I foist a trivial review onto you?
[11:11] <bigjools> and me please! *2
[11:11] <gmb> allenap, bigjools: Queue 'em up.
[11:11] <allenap> gmb: Danke.
[11:11] <bigjools> buckets
[11:26] <jtv> gmb: did you change your mind about my branch?
[11:26] <gmb> jtv: No, but I've had poolie's branch in my queue since Friday
[11:26] <gmb> Seemed a good idea to get it out of the way first.
[11:26] <jtv> gmb: ironically, he owes me one.
[11:26] <jtv> I traded reviews with him, but never got mine.
[11:27] <gmb> Shocking behaviour.
[11:27] <jtv> (And at that time he couldn't have known how rough I'd be on his, heh heh)
[11:27] <gmb> :)
[11:32] <gmb> jtv: r=me
[11:35] <jtv> gmb: thanks
[11:38] <gmb> allenap: r=me
[11:38] <allenap> gmb: Cheers :)
[11:52] <gmb> bigjools: r=me * 1
[11:52] <bigjools> gmb: thanks - the other one errored on the email MP proposal, I just did another by hand
[11:53] <gmb> bigjools: Yep, looking now. So is this one a correction of the stuff that we rammed in on rollout day?
[11:53] <gmb> Or am I confusing different 'enabled' fields
[11:53] <bigjools> gmb: not exactly but nearly - the rollout day change was just the db change
[11:53] <gmb> Ah, yes. Of course.
[11:53] <bigjools> I need to tweak the code now
[11:53] <gmb> Cool
[11:53] <bigjools> if you need help understanding the test let me know
[11:54] <gmb> k
[11:54] <bigjools> you need to know how arch-all publishing works to appreciate it :)
[11:55] <gmb> bigjools: The test makes sense to an extent but for the sake of completeness... how does arch-all publishing work ? :)
[11:56] <bigjools> gmb: although the binary is only built in one architecture, it has to be published everywhere
[11:57] <bigjools> the code I tweaked calculates the other archtectures for publishing
[11:58] <gmb> Right.
[11:58] <gmb> bigjools: Pretty much as I thought, then.
[11:58] <bigjools> ok cool
[11:58] <gmb> bigjools: r=me; looks good
[11:58] <bigjools> thanks gmb
[11:58] <gmb> np
[12:00] <bigjools> ah wgrant is stalking me again
[12:00] <wgrant> bigjools: Yeah, sorry.
[12:01] <wgrant> I didn't see it was being discussed in here.
[12:01] <bigjools> wgrant: I'll fix copying separately
[12:01] <wgrant> Hmmm.
[12:01] <wgrant> I suppose.
[12:02] <bigjools> it could do with refactoring
[12:02] <wgrant> I'm also slightly worried about letting new binaries through the publisher unchecked. But I guess that's not a huge problem.
[12:02] <bigjools> anyway the urgent case is the upload one
[12:02] <bigjools> unchecked?
[12:03] <wgrant> I think I'd prefer it if the publisher whinged if it tried to publish binaries in a disabled arch.
[12:03] <wgrant> This is messy :(
[12:04] <bigjools> what about the case where you want to delete?
[12:04] <wgrant> Hm?
[12:05] <bigjools> actually, hmmm, getPendingPublications doesn't look for that
[12:05] <bigjools> it could whinge but it's not necessary - preventing creating publications is the important bit
[12:06] <wgrant> I guess we can fix any screwup there later.
[12:06] <wgrant> It's the indices that are the important bit.
[12:06] <wgrant> Since they can never change after release.
[12:06] <bigjools> yes
[12:07] <wgrant> But copies need to be fixed soon, since there'll be SRUs possibly even before release.
[12:11] <wgrant> Hrrrrrm.
[15:30] <bigjools> gmb: can you please review the extra revision I added to the second branch you did for me earlier?
[15:31] <bigjools> it adds another check - yay for duplicated code logic. (bug filed BTW)
[15:31] <gmb> bigjools: Sure.
[15:31] <gmb> bigjools: What's the MP URL again?
[15:32] <bigjools> gmb: https://code.edge.launchpad.net/~julian-edwards/launchpad/no-disabled-arch-publications-bug-648715/+merge/36838
[15:32] <bigjools> cheers
[15:33] <bigjools> whoever in the Code team added the partial diff attachment processing, you're totally awesome
[15:34] <gmb> +1. That's the first time I've seen that.
[15:34] <bigjools> it's been there for a while
[15:34] <gmb> bigjools: Yeah, but no-one ever does any work round here.
[15:34] <bigjools> Lancaster?
[15:34] <bigjools> :)
[15:35] <gmb> Touche.
[15:35] <gmb> bigjools: r=me on the changes.
[15:36] <bigjools> gmb: thanks muchly
[15:36] <gmb> np
[15:52] <abentley> gmb, leonardr: Could you please review https://code.edge.launchpad.net/~abentley/launchpad/incremental-diffs/+merge/36875 ?
[15:55] <leonardr> abentley, sure
[15:55] <abentley> leonardr: thanks.
[16:22] <jcsackett> gmb or leonardr: time for a review?
[16:22] <leonardr> jcsackett, put it in the queue
[16:23] <jcsackett> leonardr: you got it. MP is https://code.edge.launchpad.net/~jcsackett/launchpad/bad-state-transition-641266/+merge/36726
[16:23] <leonardr> jcsackett: and give me the mp url
[16:24] <jcsackett> one step ahead of you. :-P
[16:36] <leonardr> abentley, all the fields in IIncrementalDiff are exported, but you don't call export_as_webservice_entry(). do you want these objects to be published through the web service?
[16:37] <abentley> leonardr: I guess so.
[16:38] <abentley> gmb, leonardr: Could you please review https://code.edge.launchpad.net/~abentley/launchpad/incremental-diff-job/+merge/36881 ?
[16:38] <leonardr> abentley: try running the webservice tests with your branch as-is and see if you get any failures. i'm curious.
[16:39] <gmb> abentley: I'll take a look at that branch for you.
[16:39] <abentley> leonardr: How do I do that?
[16:39] <abentley> gmb: thanks.
[16:39] <gmb> ... after I've looked at jcsackett's. Argh; spent too much time looking at tests and am now all turned about.
[16:45] <leonardr> abentley: bin/test -vvt webservice
[16:50] <leonardr> abentley: even if the existing webservice tests pass, i suspect your branch will break as soon as someone does something to retrieve a diff from the web service, and the diff they get happens to be an incremental diff
[16:50] <abentley> leonardr: No, I don't think so.  Incremental diffs aren't diffs, and don't have any URL at all.
[16:51] <leonardr> abentley: in that case, i don't think you need to call exported() on their fields
[16:53] <abentley> leonardr: So either I should go all the way and export incremental diffs over the API, or I should drop the export calls?
[16:53] <leonardr> abentley: exactly. export() is you telling lazr.restful which parts of the incremental diffs should be visible
[16:54] <abentley> leonardr: Fair enough.  I'll probably export them, just because sooner or later, we'll get bug reports if I don't.
[16:55] <leonardr> abentley: bug reports saying "export these pls"?
[16:55] <abentley> leonardr: yeah.
[16:55] <leonardr> abentley: ok, i think you should do that in a separate branch
[16:55] <leonardr> since you'd also have to give an incremental diff a url
[16:56] <abentley> leonardr: okay.
[16:57] <leonardr> abentley, is an incremental diff really a 'thing' with an independent existence? it seems more like the product of an algorithm. that doesn't preclude giving it a url, but it might make the work more complicated
[16:58] <abentley> leonardr: You could look at it as merely cached data.
[16:58] <abentley> leonardr: Same for any diff, I guess.
[16:59] <leonardr> abentley: at this point we're beyond a review of this branch, but if you get into this, maybe we can talk about how existing diffs are published in launchpad-dev?
[17:01] <abentley> leonardr: sure.
[17:02] <leonardr> abentley: can you explain this line? IMasterStore(IncrementalDiff).add(incremental_diff)
[17:02] <leonardr> are you caching the diff in the database for later?
[17:04] <leonardr> and what's the difference between IMasterStore.of() and Store.of()? it looks like one takes a class and the other an instance?
[17:04] <abentley> leonardr: I am storing the value in the database.  We cannot generate incremental diffs on demand.  We will generate them in a cron job
[17:05] <abentley> leonardr: IMasterStore(class) returns the writable store that is meant to be used for that class.  Store.of(instance) returns the store the the instance was retrieved from.
[17:05] <leonardr> abentley: ok, that does give the incremental diff an independent existence
[17:11] <abentley> leonardr: export removed, diff is updated.
[17:12] <abentley> leonardr: s/export/expose
[17:19] <leonardr> abentley, line 292, i think the end quotes need to be on their own line
[17:21] <abentley> leonardr: done.
[17:21] <leonardr> going through tests now
[17:25] <gmb> abentley: r=me on the incremental diff job branch with a few small changes requested.
[17:25] <leonardr> abentley, i think in test_generateIncrementaldiff there are several multi-line loc you could combine and stay under the character limit
[17:25] <abentley> gmb: thanks.
[17:26] <sinzui> leonardr, I have a branch the refactors our rdf page.
[17:26] <leonardr> and i could really use some comments explaining what all these branches have to do with each other. it's tough to figure out just by looking
[17:26] <leonardr> sinzui: ok, send me the mp
[17:26] <sinzui> https://code.edge.launchpad.net/~sinzui/launchpad/rdf-links-1/+merge/36865
[17:27] <leonardr> abentley: or some more expressive commits--right now all the commits are nearly identical except for one or two single-character differences
[17:28] <leonardr> i think it would help a lot to have a comment explaining the original state of the precursor branch, the state of the prerequisite branch, and then the changes made by the new branch
[17:28] <abentley> leonardr: I was only able fix one multi-line loc.
[17:28] <leonardr> abentley: ok, i must have misjudged. what do you think of the comment idea?
[17:29] <abentley> leonardr: Sure, I can do that.
[17:29] <leonardr> a way to make it simpler without comments would be to have a method that both creates a branch and does a commit
[17:36] <abentley> leonardr: http://pastebin.ubuntu.com/502197/
[17:37] <abentley> leonardr: half of those commits are merges, though.
[17:39] <leonardr> abentley: that makes it a lot clearer
[17:40] <leonardr> i don't know if the method that creates branch and does commit would help much, but it might help distinguish between the branches as they were "before", and the branches that get changed "during" the test
[17:42] <leonardr> abentley: a couple nosy questions about difftacular, which i see you wrote yourself during july (?)
[17:42] <leonardr> how hard would it be to make an egg of it? i get the impression we prefer eggs to sourcedeps
[17:43] <leonardr> granted that you have tests in difftacular, but did you get someone to review that code?
[17:43] <abentley> leonardr: impossible.  bzr plugins cannot be provided as eggs.
[17:44] <leonardr> ok
[17:45] <abentley> leonardr: I did not get someone to review that code.
[17:45] <abentley> leonardr: I'm sorry, but I need to go now to meet someone for lunch.
[17:48] <leonardr> abentley: no problem. i'll approve this mp with your changes, contigent on getting difftacular reviewed. i can probably review it today if it's not too complicated, since i need to leave some mps for a trainee who's ocr tomorrow
[18:21] <leonardr> sinzui, just out of curiosity, have people been complaining about the rdf and the owl?
[18:22] <sinzui> leonardr, none directly...they cannot find it. We have circuitous complaints that RDF is not documented
[18:23] <sinzui> oh, Google knows about it
[18:23] <sinzui> bots don't complain though, they just 404
[18:40] <leonardr> sinzui, obvious typo: "it's" in line 204
[18:40]  * sinzui can fix that
[18:43] <leonardr> sinzui: it looks like there was a problem where both the rdf spec and the link to it were called "rdf". was that the actual source of the problem (like a conflict) or was it just something that looked confusing so you fixed it?
[18:44] <EdwinGrubbs> abentley-lunch: I didn't get the job runner cron script ready in time for your OCR day. Do you have time to review it now, or do you know someone else who is familiar enough to handle it?
[18:44] <sinzui> leonardr,  that was part of the problem. browser resource loses the mimetype. lazr folder fixes that
[18:45] <sinzui> leonardr, I think it was first broken because the director or zcml moved and the publisher could not find the dir.
[18:45] <leonardr> sinzui: i see
[18:45] <leonardr> ok, r=me
[19:51] <abentley-lunch> EdwinGrubbs: I can look at it now.
[19:52] <leonardr> abentley-lunch: when you have time, i've looked through the difftacular codebase and i have some questions at various granularities
[19:54] <abentley> leonardr: sure.
[19:54] <leonardr> abentley: my biggest problem is that i don't understand what ignore_heads does
[19:55] <leonardr> it looks like it takes one branch, and a bunch of other branches, and returns a bunch of revision ids in the first branch that can be ignored?
[19:57] <abentley> leonardr: it's the changes introduced by those revisions that can must be ignored.
[19:58] <leonardr> abentley: how about iter_lca_revision? i don't know what an lca is, but i'm guessing this is what strips out the revisions to be ignored?
[20:00] <abentley> leonardr: an LCA is a Least Common Ancestor.  It is an ancestor shared by both revisions that has no descendants that are also ancestors of the revisions.
[20:01] <leonardr> so the revisions included in the diff are the lcas of the original revision and all the revisions being ignored?
[20:03] <abentley> leonardr: we don't really diff revisions.  We generate two trees and diff those.
[20:03] <abentley> The "new" tree is the tree for the "new_revision".
[20:04] <abentley> The "old" tree is generated by merging the changes from the ignore_branches that were merged into the new_revision into the old_revision as well.
[20:04] <EdwinGrubbs>  abentley: thanks, here it is: https://code.edge.launchpad.net/~edwin-grubbs/launchpad/bug-615654-jobqueue-cron-script/+merge/36910
[20:04] <leonardr> ok, that's similar to what i was trying to say
[20:04] <leonardr> let me take another look at the tests now that i understand ignore_heads
[20:05] <abentley> EdwinGrubbs: I am looking into it, but I am also multitasking pretty hard.
[20:05] <EdwinGrubbs> abentley: no problem, I need to get some lunch anyway.
[20:13] <leonardr> abentley: why does ignore_heads return an empty list in test_ignore_heads_already_merged? is it because the merge happened in rev2, not between rev2 and rev3?
[20:18] <abentley> leonardr: it is because those branches haven't been merged into bar.
[20:19] <leonardr> oh, they were merged into foo and you checked bar
[20:19] <leonardr> no, i'm confused again. 'repo' is foo.branch.repository
[20:19] <leonardr> you're generating a diff between foo rev2 and foo rev3
[20:19] <leonardr> and you're ignoring bar
[20:20] <leonardr> but bar was merged into foo during rev2, so it doesn't show up
[20:20] <leonardr> that makes sense to me, but it's not what you're testing?
[20:21] <abentley> leonardr: sorry, misread it.
[20:21] <abentley> leonardr: yes, your original idea was right.
[20:21] <leonardr> ok
[20:22] <leonardr> abentley: hopefully the final question before the suggestions
[20:23] <leonardr> what exactly is going on in the unignored merge scenario?
[20:23] <leonardr> i suspect it's not unignored on its own, but that you use it in a way where bar.branch is not ignored where it would otherwise be ignored
[20:25] <leonardr> or, you create a new branch, merge it into foo, and its changes are picked up while bar's changes are ignored
[20:27] <abentley> leonardr: I don't understand what "unignored on its own" would mean.  Everything depends on how you invoke the diff generation.
[20:28] <leonardr> abentley: i don't think "unignored on its own" has any meaning, but "create_unignored_merge_scenario" implies that it does
[20:29] <leonardr> i'm trying to figure out what is special about the scenarios where you call that functino. such that the "unignored" branch is not ignored
[20:30] <abentley> leonardr: I think it means that the merge would not be ignored if you did a normal diff.
[20:31] <leonardr> abentley: in the two tests where you use it, the merge is *not* ignored. you ignore bar instead, and the "d" line shows up in the diff
[20:32] <leonardr> which makes sense, given the name. i'm just not sure whether that's what you're testing
[20:33] <abentley> leonardr: I'm testing that when the branch isn't in the list of branches to ignore merges from, its merges aren't ignored.
[20:34] <abentley> leonardr: unlike mainline_diff, which will ignore such merges.
[20:34] <leonardr> ok, i get it now, but it's confusing that the tests are called "ignore_x" and you're checking that only *certain* x are ignored
[20:38] <leonardr> abentley: for lack of a better place to put these comments, i'm going to append them to my review of your launchpad branch
[20:39] <abentley> leonardr: okay.
[20:51] <leonardr> abentley: i've approved your launchpad branch. let me know when you do a difftastic follow-up and i'll review that
[20:57] <abentley> leonardr: the preview tree must be used as the input to the next merge.  Otherwise, you're not doing proper merges.
[20:59] <leonardr> abentley: ok, i missed that you were reassigning tree
[21:08] <abentley> EdwinGrubbs: "for child in children: child.wait()": doesn't this mean that you can't re-run a job source until all job sources have terminated?
[21:12] <abentley> EdwinGrubbs: I was thinking that we would exit after all the JobSources had been forked, not after they all completed.
[21:12] <EdwinGrubbs> abentley: I guess it does. The problem I was having is that if the parent process doesn't wait for the children to exit, when you run it manually, the child processes continue to spew output to the terminal. One solution to this problem would be to not have the parent process use a lockfile, since the child processes already have their own lockfiles.
[21:12] <abentley> EdwinGrubbs: All the output should be redirected to logfiles anyhow.
[21:15] <abentley> EdwinGrubbs: Waiting doesn't prevent the children from spewing output to the terminal, it just means they won't do it while you're using the terminal for something else.  Which isn't really a risk for cron scripts.
[21:16] <EdwinGrubbs> abentley: To prevent it from becoming more complicated to gather the output in the tests, I think I should add a command-line option so the tests can force it to wait, but I'll try running the tests without the waiting to see if that works at all.
[21:19] <EdwinGrubbs> I meant "spewing" to indicate that the output was coming at an annoying time. I actually wanted the children's output, but I just didn't want to be surprised by it.
[21:20] <sinzui> bac: those stories do not ready like a story. should we be concerned that foo bar is being called an owner in a story?
[21:20]  * sinzui thinks stories need an owner/contributor browser and that is Sample Person
[21:20] <bac> sinzui: yes, it required more set up
[21:21] <sinzui> who owns applets?
[21:21] <bac> sinzui: i welcome ideas on how to make it looks less mechanical
[21:21] <bac> sinzui: either foobar or sample
[21:21] <abentley> EdwinGrubbs: Why do you default runner_class to JobRunner when an unknown runner class is specified?
[21:21] <sinzui> The code team have been turning their mechanical tests into unittests that still use testbrowser
[21:22] <bac> sinzui: foobar owns applet
[21:22]  * sinzui bangs head on a wall
[21:23] <sinzui> The whole test is using a god to manage an upstream project
[21:23] <bac> sinzui: i didn't intend for this to spiral.  i made requested UI changes and broke the world.  and then backfilled.
[21:23]  * bac bad
[21:23] <sinzui> bac: right. I am thinking how do we stop hurting ourselves with this.
[21:24] <abentley> EdwinGrubbs: What about phrasing it like this? http://pastebin.ubuntu.com/502299/
[21:24] <sinzui> bac: did you check for test duplication? maybe we can delete instead of add to make it pass
[21:24] <EdwinGrubbs> abentley: oh, that was left over from the old solution. It handled defaulting to JobRunner if it didn't exist, but getattr() wouldn't default to JobRunner if it was set to null. Although, it's unlikely that someone will specify the field without filling it in with something valid, so I could probably go back to just using getattr() and let it blow up later if the config is invalid.
[21:25] <bac> sinzui: no, i didn't look carefully for duplicates.  being unfamiliar with the code tests i'm thinking that would take a while
[21:25]  * sinzui takes a quick look
[21:25] <EdwinGrubbs> abentley: that's a nice rewrite. I'll use that.
[21:25] <abentley> EdwinGrubbs: I think it's better if it blows up the value is invalid.
[21:26] <sinzui> bac: code/browser/tests does not appear to intersect
[21:27] <sinzui> oh, the list is nice
[21:27] <bac> what list?
[21:29] <bac> sinzui: ^
[21:29] <sinzui> bac: I like the listification of the hosting options
[21:29] <abentley> EdwinGrubbs: Do you need NoErrorOptionParser?  Can't you just blow up in ProcessJobSource.__init__?
[21:30] <bac> sinzui: yes, +1 to mrevell for the suggestion
[21:30] <sinzui> bac: I have been thinking about privacy too long. I keep seeing context/displayname and thinking that will raise a 403
[21:32] <EdwinGrubbs> abentley: the problem is if I want to pass "-v" into ProcessJobSource, the OptionParser in the __main__ section needs to ignore it.
[21:32] <sinzui> bac: you cleaned up a generator, but 'v' is does not conform to lp standards
[21:33]  * sinzui argued for 1-char vars in comprehensions
[21:33] <bac> sinzui: i'll join you in that argument
[21:33] <bac> but for now i'll fix it
[21:33] <abentley> EdwinGrubbs: But if you do the argument parsing in ProcessJobSource.__init__, you'll have the real parser available to you.
[21:34] <bac> sinzui: and then have to split the line, resulting in it being more unreadable
[21:35] <sinzui>  bac: branch-listing.pt may render faster if we used "sprite branch" instead to using an <img> element 75 times
[21:35]  * sinzui was confused
[21:35] <bac> sinzui: IRC hide-n-seek?
[21:35] <EdwinGrubbs> abentley: yes, but I can't get the real parser until after I parse the JOB_SOURCE name out of the command line arguments, since that is necessary for looking in the configs to find out which runner class to pass to ProcessJobSource.__init__().
[21:35] <sinzui> maverick has enabled tap on my magic mouse :(
[21:36] <abentley> EdwinGrubbs: You mean which job source class to pass to ProcessJobSource.__init__() ?
[21:36] <sinzui> Bac: this paste looks good. I do not see what can be done about the tests. Given the age and value of the branch, I think it is ready to land.
[21:37] <EdwinGrubbs> abentley: sorry, I mean that ProcessJobSource.__init__() would be looking up the runner class, which it would be passing to JobCronScript.__init__()
[21:37] <bac> sinzui: i've made sprite change and the generator change.  thanks.
[21:40] <abentley> EdwinGrubbs: So I think the simplest thing is to override runner_class after you've done JobCronScript.__init__()
[21:43] <sinzui> bac: you have my r for code.
[21:43] <bac> sinzui: and UI?
[21:44] <sinzui> That too, am I stepping on salgado though?
[21:45] <bac> sinzui: i'll send this off to ec2 for testing and wait for salgado to reply.
[21:45] <sinzui> bac: yes please
[21:45] <mwhudson> salgado is not working today, i think, if that's relevant
[21:46] <EdwinGrubbs> abentley: ok, it looks like I just have to override config_name and dbuser also, but init_zca doesn't get called in the __init__(), so I can get rid of the extra parser.
[21:46] <bac> mwhudson: will he be around tomorrow?
[21:47] <mwhudson> bac: hopefully
[21:48] <abentley> EdwinGrubbs: have you considered providing a list of crontab_groups in [process-job-source-groups] and then providing configuration for each group?
[21:49] <abentley> EdwinGrubbs: I think then you wouldn't need all_job_sources or grouped_sources.
[21:52] <EdwinGrubbs> abentley: my main concern then is that a job class could become a member of multiple groups. Even if the cronscript would spit out an error when that happened, it would make the config file less convenient to use, and the config file will be edited a lot more than the cronscript's code.
[21:53] <abentley> EdwinGrubbs: fair enough.
[21:55] <abentley> EdwinGrubbs: could you please add documentation to your tests?  Each test is supposed to have at least one line.
[22:00] <abentley> EdwinGrubbs: is there a reason why test_setstatus_silent and test_setstatus_admin differ by more than the silent=True parameter?
[22:00] <EdwinGrubbs> abentley: ugh, another problem with not passing in the job_source to __init__() so that we can re-use its option parser is that the job_source is used to determine the config_name, and the config_name is passed to LaunchpadCronScript.__init__() as the name it uses for the cron control file, which determines whether the script runs at all.
[22:02] <abentley> EdwinGrubbs: so my meta-suggestion is "if the way things fit together is getting in our way, let's fix it instead of routing around it or doing double handling".
[22:03] <EdwinGrubbs> abentley: I'll add some comments to the tests. setStatus(silent) can only be done by a Launchpad admin, so I made extra changes for that restriction after I had already finished test_setstatus_admin(), which just refers to the team admin.
[22:04] <abentley> EdwinGrubbs: since you're doing admin =<EMAIL_ADDRESS>you can use login_person instead of login, if you like.
[22:05] <lifeless> also, if I can suggest
[22:05] <lifeless> from lp.testing.sampledata import ADMIN_EMAIL
[22:07] <abentley> EdwinGrubbs: Have you tried using canonical.launchpad.scripts.tests.run_script?
[22:09] <EdwinGrubbs> abentley: no, I just copied the first test for a cronjob that I found.
[22:10] <abentley> EdwinGrubbs: Perhaps I should have gone back and fixed all the tests to use that when I wrote it, but I was not very aggressive back then.
[22:11] <EdwinGrubbs> abentley: regarding your meta-suggestion, I think it will all work better if I move all the setup logic from __init__() to run() in all the parent classes. The only downside is that it will create the lockfile briefly before it exits if the cron crontrol file tells it not to run.
[22:12] <EdwinGrubbs> abentley: I'll switch to run_script.
[22:14] <abentley> EdwinGrubbs: that sounds reasonable.
[22:14] <abentley> EdwinGrubbs: (moving the setup logic to run) sounds reasonable.
[22:16] <abentley> EdwinGrubbs: It's past EOD for me.  Can we pick this up tomorrow?
[22:17] <EdwinGrubbs> abentley: sure, talk to you later
[22:17] <abentley> EdwinGrubbs: cool.


[00:24] <badfish69> joetheodd: what do you want?
[00:24] <joetheodd> badfish69, that's the kernel used in jaunty
[00:24] <joetheodd> badfish69, 2.6.28
[03:35] <Lasivian> I just scared myself shitless by forgetting the errors on the screen were the BSOD screensaver
[03:37] <Killeroid> lol
[04:53] <mikechelen> rofl
[04:54] <mikechelen> someone installed windows on my linux box, and it crashed!
[05:08] <calc> Lasivian: linux might get bluescreens in the next year or so :)
[05:34] <calc> anyone upgraded to karmic yet?
[05:34] <rww> calc: considering that it doesn't exist, no :P
[05:34] <calc> look in the archive :)
[05:34] <calc> its there already
[05:35] <calc> nothing new in it yet i imagine
[05:35] <calc> i'll have to see if i can get OOo 3.1.0 uploaded in the next day or two
[05:35] <ajmitch> calc: no major toolchain changes hitting first?
[05:35] <rww> calc: I would do that, but the archive is slow for some reason. Can't imagine why ;)
[05:35] <calc> ajmitch: those hit sometime this week as well
[05:35] <calc> rww: heh
[05:36]  * ajmitch thought that uploads were usually held off until all that built
[05:36] <calc> ajmitch: i'm on a deadline so if they are just frozen that is fine with me
[05:36] <ajmitch> I might even do some work on ubuntu this release cycle, if I have time :)
[05:36]  * calc moves to another dept next friday (may 1)
[05:36] <ajmitch> ah
[05:36] <ajmitch> able to tell us which dept? :)
[05:37] <calc> i'm pretty sure it was discussed publically in the desktop meeting... i'll be working on the canonical oem team for about 6 months
[05:37] <calc> still doing OOo work as well but not as much time for it for this next release cycl
[05:37] <calc> e
[05:37] <ajmitch> great
[05:38] <ajmitch> you've been brave to maintain OOo for all this time
[05:38] <ajmitch> it's been appreciated
[05:38] <calc> :)
[05:38] <calc> hopefully the oracle buyout will help move OOo into being more community managed
[05:38] <ajmitch> we'll see
[05:39] <ajmitch> it'll probably take awhile for things to settle down there
[05:39] <calc> i would really like to see OOo split into separate source bits, converted to gettext, and FHS compliance :)
[05:39] <calc> not sure if that will ever happen but with Sun out of the picture it might be possible :)
[05:39] <ajmitch> if there are people who care enough to get it done it may happen
[05:40] <calc> autotools would be nice as well, heh
[05:40] <calc> yea once its no longer a Sun product it could be done, before that though it would be way to hard to deal with
[05:41] <calc> i'm going to wait to upgrade my wife's computers to jaunty until after UDS
[05:41] <calc> make sure all the ugly bugs are shaken out :)
[05:43] <ajmitch> a wise move if you're going to be away for a few weeks :)
[05:43] <calc> yea
[05:43] <calc> plus after a release more bugs are always found
[05:43] <ajmitch> I just need to get into something for karmic that I can work on & that will interest me
[05:44]  * ajmitch has been slacking for too long
[05:44] <calc> i got a bug report about people not being able to save old ods spreadsheets for some reason, that i didn't get until today even though OOo 3.0.1 debs had been available for hardy/intrepid/jaunty for the past 4 months
[05:44] <ajmitch> besides, my core dev membership is set to expire sometime before karmic release
[05:44] <calc> yea
[05:46] <ajmitch> plus it'd be fun to go to UDS again one day :)
[05:47]  * calc wonders where 10.04 UDS will be
[05:48] <ajmitch> probably in the US somewhere
[06:10]  * calc thinks it should be somewhere in SA like Rio
[06:10] <calc> er South America
[06:10]  * calc realized there are other expansions of SA, heh
[06:56] <ajmitch> hm, they did talk about doing it in brazil at one point, I think
[08:02] <Cycom> cd ..
[08:02] <Cycom> erm yeah
[16:59] <mphill> how long after a release are the next release repos created?
[21:40] <Killeroid> !help
[21:55] <Killeroid> !legacy
[22:47] <der0b> heya folks, cheers to the team that put jaunty together.  best release yet.  Nice :D


[00:11] <pfifo> I think im going to switch to ubuntu and help out with 14.04
[00:41] <Xabster> Hi, fresh install of 13.10 - sound is not working and I'm a newbie to ubuntu, so where do I start figuring out why?
[00:57] <SolarAquarion> i installed gnome 3.10 on ubuntu via a PPA and I would like to know how to revert the changes to unity/gnome
[01:04] <pfifo> reinstall?
[01:06] <SolarAquarion> sounds good
[01:12] <SolarAquarion> pfifo, that won't work.  the deps are all fucked up now because gnome 3.10
[01:12] <pfifo> I meant format the disk and reinstall ubuntu
[01:13] <SolarAquarion> pfifo, how do i save all the stuff I have on my system
[01:15] <pfifo> depends on your system, I have a seprate partition for /home so if I do a reinstall nothing needs to be done, i just format the root partition where ubuntu's stuff is
[01:16] <SolarAquarion> pfifo, how do i save my /home partition when everything was default
[01:26] <wilee-nilee> SolarAquarion, There is a wiki on separating home, and please don't swear.
[01:27] <SolarAquarion> wilee-nilee, please link
[04:13] <snadge> wheres somewhere i can talk or ask about gnome flashback?
[04:14] <snadge> its not really a general support question.. i could try #ubuntu but :| .. its not really a social topic either
[04:15] <wilee-nilee> snadge, #ubuntu-offtopic
[04:19] <wilee-nilee> snadge, might worth being aware of. https://wiki.gnome.org/GnomeFlashback
[04:20] <snadge> thankyou very much! thats exactly what i was after
[04:20] <snadge> apparently the fedora folk arn't aware of the existence of flashback
[04:20] <jmite> Does anybody know how to install Steam in Saucy? I've tried the .deb from the steam website, but it can't connect to the network. (I have similar network problems with the netflix-desktop program)
[04:20] <wilee-nilee> never heard of it myself, but I was the fallback, google is an easy search
[04:21] <snadge> i wonder why the rename? .. perhaps its to distinguish it from gnome classic
[04:21] <snadge> the gnome classic session is part of upstream gnome.. and thats what fedora uses
[04:21] <snadge> flashback is something debian/ubuntu specific
[04:21] <wilee-nilee> jmite, You using straight internet access no proxy...etc?
[04:26] <jmite> Yep, no proxy that I know of. Firefox and Thunderbird connect just fine.
[04:26] <jmite> It does go through a wireless router... is there a specific port that I'd have to enable?
[04:27] <wilee-nilee> jmite, Not sure the netflix is through wine steam I have never used, I had netflix for a minute and it worked fine, but not in saucy.
[04:29] <jmite> This is team native, not steam wine. But yes, netflix is through wine.
[04:30] <jmite> I have  the command line output from steam here: https://github.com/ValveSoftware/steam-for-linux/issues/2880
[04:30] <jmite> *steam
[04:33] <wilee-nilee> jmite, Not really an area I know a lot about, if it were me though I would be doing this in 12.04 probably for the long term support, then upgrade to 14.04 if needed.
[04:34] <wilee-nilee> In general I use the latest releases including the development but my installs are pretty basic.
[04:34] <wilee-nilee> no wine no games just some ppa's
[04:35] <jmite> Yeah... it worked fine in 13.04...
[04:38] <wilee-nilee> I have W8 for windows stuff mainly just word for college papers, go it cheap with a student discount, I started on open source but W8 is not a bad OS in general, help being a open source user when using it in general I think.
[04:38] <wilee-nilee> got*
[04:39] <jmite> Honestly, netflix and Steam are the only two things keeping me on Windows.
[04:41] <wilee-nilee> Heh, I never used windows, I started on open source, just happened to get a computer for college from a recyclers that kicks out the ubuntu LT's
[04:42] <wilee-nilee> I was a linux fanboi for about a minute, they are all OS's to me in the end.
[04:51] <jmite> Anybody else have ideas for my networking issue?
[08:10] <Volkodav> I am trying to fix the system from yesterday's failed upgrade from 13.04 in chroot env and managed most of it but ran into this dependency situation with the kernel:  http://pastebin.com/Qivb00E2     Any ideas someone&
[08:12] <Volkodav> apt-get install -f  and dpkg --configure -a   gets the same output as in the latest with upgrade
[08:17] <alankila> There's already a new kernel image. I don't know what's going wrong with your chroot'd update attempt, though.
[08:18] <Volkodav> alankila: What's the new one I may try that one
[08:18] <alankila> -11
[08:18] <alankila> don't know anything about it, it just arrived when I apt-get dist-upgrade'd
[08:18] <Volkodav> hmm let me see
[08:57] <Volkodav> alankila: I managed to reboot in old kernel and upgrade from there - all good so far
[09:26] <Xabster> Oh man, I plunged into the beta with not much experience in Ubuntu or linux in general, and now I'm screwed -- lots of stuff does not work and now I'd like to test a non beta version but the "startup disk creator" application crashes on 41% while trying to make me a live USB of 13.04 :(
[09:28] <TheOnlyJoey|Lap> Xabster, try unetbootin
[09:30] <Xabster> downloaded it from sourceforge but the file has no extension and i tried sudo sh unetbootin-linux-585
[09:31] <Xabster> says it can't open it
[09:32] <Xabster> wait, think i got it
[09:33] <Xabster> nope (i tried making it executable)
[09:33] <Xabster> libpng12.so.0 missing it seems
[09:34] <Volkodav> all my desktop icons disappeared in xfce session along with right click on desktop - anybode else noticed that?
[09:36] <brainwash> Volkodav: restart xfdesktop
[09:38] <TheOnlyJoey|Lap> hmm crap, i have a .xinitrc script that does some essential stuff for my GPU setup, and it works with startx, but it does not seem to work with gdm, .xsession file also does not seem to work
[09:40] <Volkodav> brainwash: it helped thanks
[09:48] <Volkodav> something is still wrong with icons - they do not open apps even newly created
[09:48] <Volkodav> can't delete them either
[10:06] <Kajover> hi i am using a lenovo t440s... with 13.10 daily as i had problems with the wifi. i just switched from windows and notice that everything opens up rather slowly... browsers, dash etc. i was wondering if maybe the intel hd4400 is not fully supported?
[10:08] <wilee-nilee> Kajover, just switching from windows to a development release is not the best solution, why 13.10?
[10:10] <Kajover> because the haswell chip needs 3.11
[10:10] <wilee-nilee> http://www.ubuntu.com/certification/hardware/201308-14073/
[10:11] <Kajover> everything works just fine... its just a bit slower. i am not sure if the intel hd is not fully implemented
[10:11] <Kajover> it wasnt preinstalled by a manufacturer
[10:14] <BluesKaj> Hey folks
[10:24] <seriously_random> Do I need special boot option to enable new radeon power management or is it switched on by default?
[10:26] <Kajover> if i am staying on the daily build will this eventually become stable or will it switch to the daily cycle of 14.04?
[10:27] <wilee-nilee> Kajover, the daily build is just a snapshot for install you only upgrade if you choose to.
[10:27] <seriously_random> wilee-nilee, that's now what he asked
[10:27] <seriously_random> *not
[10:28] <wilee-nilee> stable is not answerable, what is it's definition?
[10:28] <Kajover> will this switch to the stable branch
[10:28] <wilee-nilee> its a subjective opinion.
[10:29] <Kajover> to the officially released 13.10
[10:29] <seriously_random> I think the question is if daily build == 13.10
[10:29] <wilee-nilee> Kajover yes if you update upgrade it is the same as any 13.10 install.
[10:29] <seriously_random> AFAIK, yes
[10:29] <Kajover> if it is going to stay at 13.10 or will it switch to the next daily cycle of 14.04
[10:30] <Kajover> am i going to receive a notification or am i going to go to the terminal and dist-upgrade
[10:30] <wilee-nilee> Kajover, dailies are just the development up to that day is all, once installed it is only a daily in name.
[10:30] <wilee-nilee> no distro upgrades without choosing it.
[10:31] <Kajover> so what do i have to do to switch from this daily to the stable branch, the official release of 13.10 when it comes out?
[10:32] <Kajover> is the software updater going to notify me or do i need to dist-upgrade (terminal) or reinstall?
[10:32] <Kajover> or upgrade with the usb stick in live mode
[10:32] <wilee-nilee> Kajover, update/upgrade and on release it will be the release, stable is a misnomer it is an opinion, what you think is stable maynot be to others.
[10:32] <seriously_random> !radeon
[10:33] <Kajover> ok thank you. i understood now
[10:33] <brendand> wilee-nilee, stable is not a misnomer. 'stable' as in the code doesn't change except by a strictly defined process
[10:33] <brendand> wilee-nilee, not stable as in 'won't crash'
[10:33] <wilee-nilee> that is your opinion
[10:34] <brendand> wilee-nilee, not really - that's what a stable branch means
[10:35] <BluesKaj> if it crashes it's effectively not stable , definitions or no
[10:35] <wilee-nilee> try telling that to those that have problems, the problem is that stable has a different definition for different people. It is to broad a statement, it sounds nice but does not play out that way for everyone.
[10:36] <wilee-nilee> people tweak away, if it was a vanilla install, you might be able to claim stability
[10:36] <BluesKaj> stable branch is just a name
[10:36] <wilee-nilee> exactly
[10:36] <wilee-nilee> not a belief, lol
[10:36] <brendand> BluesKaj, yes - a name with a meaning
[10:37] <wilee-nilee> in yhour mind
[10:37] <BluesKaj> for those who wrote the code perhaps
[10:37] <brendand> or those who write code full stop
[10:38] <wilee-nilee> and code is founds to contain weaknesses, usually in security so you than see updates, nothing is perfect.
[10:39] <brendand> nobodies saying it is
[10:39] <BluesKaj> bred well, ask the guy who uses stable branch that crashes , he foes to #ubuntu for support , ask him what stable means ?
[10:39] <brendand> that's exactly the point i'm trying to make - stable doesn't mean perfect in this instance
[10:40] <BluesKaj> brendand,^
[10:40] <brendand> BluesKaj, well if somebody has told him it's 'stable' he might assume it means it won't break
[10:41] <BluesKaj> of course
[10:41] <brendand> BluesKaj, so terminology like 'stable branch' shouldn't be used on end-users
[10:41] <BluesKaj> doesn't make it so , brendand
[10:41] <wilee-nilee> that was my point, the definition of stable is going to vary with users, and should be carefully used as a term
[10:42] <brendand> BluesKaj, that doesn't mean as engineers we shouldn't be allowed to use perfectly suitable terminology to describe the point when a code branch is subject to no (or restricted) change
[10:42] <brendand> wilee-nilee, officially it is not called 'stable', it's called 'released'
[10:42] <BluesKaj> perhaps stable branch should be defined on the DL site or documentation , I haven't checked
[10:43] <wilee-nilee> brendand, Heh now you are arguing with yourself that is what I said basically, I never claimed any stability anywhere.
[10:43] <brendand> BluesKaj, if you find it on any ubuntu.com page please point it out
[10:43] <brendand> BluesKaj, use of the term 'stable'
[10:44] <BluesKaj> like I said , brendand , I haven't checked
[10:44] <brendand> wilee-nilee, i'm really not arguing with myself. my only point was that stable is a term with a particular meaning and it's not an 'opinion' when used properly
[10:45] <brendand> wilee-nilee, when used improperly of course it will cause confusion
[10:45] <Kajover> another question.. where can i set up the fingerprint login?
[10:45] <wilee-nilee> I have rarely had a problem with ubuntu since dapper, in my version of reality I could say it's stable, however I don't think of it that way, I just use it.
[10:46] <wilee-nilee> to many variables to use stable properly in the real world, in my opinion.
[10:47] <brendand> wilee-nilee, i'd prefer to use a term like 'reliable', 'robust' or 'high-quality' to describe that kind of stable
[10:48] <brendand> wilee-nilee, there are no alternative meanings with those
[10:48] <wilee-nilee> Kajover, Not sure, you still enjoying linux, lol. ;)
[10:48] <BluesKaj> 12.04 had probs with ubquity , and it seems solved by 13.10 , but not for everyone , and it is a mystery
[10:49] <Kajover> ;)
[10:51] <wilee-nilee> brendand, The problem is that with any real statistics that are double blind empirical these are just statements, and wont play out for everyone is all. Some will not realize this and have problems, our minds tend to think in dichotomies, it is the area between these two points that have to  be realized.
[10:51] <wilee-nilee> without*
[10:52] <brendand> wilee-nilee, precisely - i hate it when people claim 'reliability' in software
[10:52] <wilee-nilee> ;)
[10:53] <brendand> wilee-nilee, eventually you'll be made to look stupid if you make such claims
[10:53] <BluesKaj> descritpive absolutes have no place in Linux OSs
[10:55] <brendand> BluesKaj, but of course the software has to be promoted somehow, so at some point descriptive absolutes do get used
[10:56] <brendand> BluesKaj, i just think 'reliable' is the worst one since that tends to be the hardest to measure and the most likely to proven to be wrong
[10:57] <BluesKaj> weii. reliable isn't an absolute , that's for sure :)
[10:58] <wilee-nilee> just vague enough to be safe, hehe
[13:22] <waldenista> Can anyone use networking? Every time I try to use the sharing option it crashes.
[13:24] <philinux> waldenista: you might try here too. http://ubuntuforums.org/forumdisplay.php?f=427
[13:24] <waldenista> thanks
[13:24] <waldenista> will give it a try
[13:25] <waldenista> I know it's beta, so not really complaining
[13:25] <philinux> waldenista: when you say networking I can see my network shared printer
[13:26] <waldenista> I mean...when I go in Files...click on say Music folder, Sharing Options, Click Share this folder, install service, ...crash every time.
[13:29] <philinux> waldenista: hang on i'll try and install it
[13:30] <waldenista> Alright
[13:30] <philinux> waldenista: same here. Sharing service installation has failed. Would you like to retry the installation?
[13:30] <waldenista> Hopefully it can get fixed before release
[13:31] <philinux> waldenista: it's reporting the problem. maybe there's a bug reoprt
[13:32] <waldenista> I reported it also. Hopefully enough people have the issue for them to pay attention. Without this, my 'real' system doesn't get updated.
[13:33] <philinux> have you a link to the bug I'll me too it
[13:33] <waldenista> hold on...
[13:34] <waldenista> sorry reported it and told system not to bother me about it again...no link
[13:35] <philinux> can you remember the title I'll find it
[13:38] <philinux> waldenista: you could install samba manually from synaptic or terminal
[13:41] <philinux> waldenista: I installed samba and I can now share folders
[13:41] <waldenista> Alright...please, steps in what you did?
[13:42] <philinux> waldenista: sudo apt-get install samba
[13:42] <philinux> the bug must be with nautilus. whats you launchpad username I'll find the bug
[13:44] <waldenista> my username is jmenzie
[13:47] <waldenista> great now networking works...thanks you so much
[13:51] <philinux> waldenista: looks like you didn't report it https://bugs.launchpad.net/~jmenzie/+bugs?orderby=-id&start=0
[13:52] <waldenista> thought I did...anyway for me to still report it or since I checked don't bother me about the bug it's gone
[13:53] <philinux> waldenista: ok i'll report it then
[13:59] <genii> After yesterdays round of updates... Cannot ctrl-alt-Functionkey to any tty from lightdm
[14:00] <BluesKaj> uhoh
[14:01] <BluesKaj> genii, that's not good , how do we rescue ourselves in an X bind
[14:01] <BluesKaj> use the recovery kernel to get to the root p-rompt I guess
[14:04] <genii> BluesKaj: It's normally how I run apt-get dist-upgrade every day
[14:05] <BluesKaj> ok genii , so you don't bother with the terminal , smaller chance of breakage or ?
[14:06] <genii> BluesKaj: Because I normally run it it like: sudo apt-get update && sudo apt-get -y dist-upgrade && sudo sync && sudo shutdown -r now  .... so if I do that from Konsole then next boot it complains about all the apps that were open crashing, etc
[14:07] <genii> Could someone else running Kubuntu confirm this behaviour?
[14:07] <BluesKaj> genii, sudo apt-get -y dist-upgrade , what's the -y do ?
[14:08] <genii> BluesKaj: Answers "Yes" when confirmation is asked about a change
[14:08] <BluesKaj> genii, I'll logout and try to get a tty
[14:08]  * BluesKaj nods , thanks genii
[14:08] <BluesKaj> ok , here gors
[14:15]  * genii sips his coffee and ponders bellybutton lint
[14:16] <BluesKaj> tty login works ok here , genii , kubuntu beta 2 , up to date as of 30 m ins ago.
[14:18] <genii> BluesKaj: OK, thanks. I updated from tty last night about 7pm. Probably something changed in between. I'll do a dist-upgrade from in the desktop then reboot and see
[14:20] <BluesKaj> ok genii , good luck :)
[14:24] <BluesKaj> genii, KDE 4.11.2 ?
[14:28] <philinux> genii: i'd loose the -y as you never know what dist-upgrade will remove. Best to looks see first
[14:54] <genii> BluesKaj: KDE Development Platform: 4.11.2, yes
[14:54] <genii> My boss keeps coming down today
[14:56] <BluesKaj> ok well work comes first
[14:57] <genii> Ok, updates done, back in a bit
[15:06] <genii> OK, works again.
[15:06] <BluesKaj> good
[15:15] <johnjohn101> oh no, no mir
[15:24] <BluesKaj> johnjohn101, ismir strictly for unity or all ubuntu destops like gnome and cinnamon ?
[15:25] <BluesKaj> not kde , we already know that
[15:26] <johnjohn101> just the announcement that mir won't be the default in 13.10.  must not be ready with two weeks to go
[15:27] <BluesKaj> ok , still experimental , for the adventurous and testers I suppose
[16:09] <genii> Meh. Firefox choked on some Flash and locked ( not new ). But after closing the browser, won't start again now.
[16:16]  * genii decides to reboot
[17:32] <genii> Still no love from Firefox
[17:36] <waldenista> In the Dash, the twitter lens does not save the choice of messages only after logout or reboot. In the Music lens. I want all my music to show up not just what I play.
[17:36] <brainwash> genii: does it lock forever? maybe it's just the 45sec timeout for the plugin-container to recover or terminate
[17:36] <genii> brainwash: Forget locking. It won't even start.
[17:37] <genii> ( even after a reboot)
[17:37] <brainwash> tried to start it from a terminal window?
[17:37] <brainwash> it may print some error messag(s)
[18:33] <Ian_Corne> 110,000 miljard koekjes
[18:52] <genii> brainwash: Just (process:2853): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed      and then back to command prompt
[19:06] <trism> genii: looks like https://bugzilla.mozilla.org/show_bug.cgi?id=833117
[19:07] <trism> might try with: G_SLICE=always-malloc firefox; to see if it starts
[19:11] <trism> though I get the same error in unity but firefox still starts here, so might not be related
[19:13] <genii> Interesting. ps aux shows it but no window comes up.
[19:14] <genii> Need reboot, back shortly
[19:26] <genii> trism: Works with the environment modified for the G_SLICE, it came up this time after boot complaining about what crashed session to restore .
[20:58] <Sander^Lap> Thanks for putting out the beta of 13.10. It's the only distro which works with my new samsung 9 series with radeon hd 8250/8280g
[20:58] <Sander^Lap> *version*
[21:32] <waldenisata> Where do I post feature request? The icon where you restart you computer, about computer, etc, was red. I had no idea why. finally I clicked on on-line accounts and there was a request for permission. Shouldn't there be a rollover pop up or something so the user don't restart system or think something else wrong.
[22:51] <pepee> something got messed up in proposed or something? :/
[22:52] <pepee> apt-get installed lots of packages yesterday (related to gcc and x32), and now it wants to remove lots of :i386 packages...
[22:55] <trism> pepee: not a good idea to run -proposed in +1
[22:55] <pepee> I know :P
[22:59] <pepee> I'l just update at night, when everything is calm...


[00:39] <jimbaker> hazmat, this looks provocative. the last line in the formula.log for wordpress/0 - 2011-04-21 23:30:08,060: twisted@ERROR: TypeError: 'NoneType' object is not callable
[00:40] <hazmat> jimbaker, hmm
[00:40] <jimbaker> so maybe the relation workflows are running, but they are going into a bad state?
[00:40] <hazmat> jimbaker, possibly
[00:41] <hazmat> surprised we don't have anything nicer in the traceback. that's unfortunate
[00:41] <hazmat> jimbaker, the status looks right
[00:41] <jimbaker> hazmat, no, it's missing the relation status info
[00:42] <hazmat> jimbaker, one option is to  have a look at the zkshell.. ensemble ssh 0 && /usr/share/zookeeper/bin/zkCli.sh
[00:42] <hazmat> jimbaker, hmmm..
[00:42] <hazmat> jimbaker, i'll have a look in the morning
[00:43] <jimbaker> compare it against this output: http://pastebin.ubuntu.com/597192/
[00:43] <jimbaker> (from an earlier run)
[00:44] <jimbaker> hazmat, sounds good
[00:54] <jimbaker> hazmat, for later consumption - shouldn't this be more than two? zk: localhost:2181(CONNECTED) 26] ls /units --- [unit-0000000000, unit-0000000001]
[01:00] <jimbaker> hmmm... maybe not that part after all - i was looking at zk_workflow_identity
[01:00] <jimbaker> it looks like it uses the same path for both ServiceUnitState and UnitRelationState
[01:01] <jimbaker> but those are not the same paths
[01:01] <jimbaker> based on looking at those specific classes
[01:01] <jimbaker> either i'm confused or ensemble is confused ;)
[01:46] <hazmat> jimbaker, they are at the same path
[01:46] <hazmat> all the workflows for a unit-agent are managed on a single node
[02:16] <jimbaker> hazmat, thanks for the clarification
[02:16] <jimbaker> this would have caused more issues if it were not the case, i guess
[02:16] <hazmat> jimbaker np.. sorry i had to run out
[02:17] <hazmat> jimbaker, yeah.. it seems strange the workflows on the unit are initialized and showing them as running the but the units weren't up or in an error state which seems strange
[02:17] <hazmat> i can't think of any reason why that would be the case.
[02:18] <jimbaker> anyway, just curious it's happening in us-west now - one more thing to try is in eu-west (if that's the other region completely set up)
[02:18] <hazmat> i'll take a look at it tomorrow
[02:18] <hazmat> jimbaker, it is
[02:18] <jimbaker> hazmat, have a good night, ttyl
[06:24] <_mup_> ensemble/refactor-to-yamlstate r197 committed by<EMAIL_ADDRESS>[06:24] <_mup_> set not taking any random data, but insisting on a dict in tests (for YAMLState)
[08:52] <kim0> Morning everyone
[13:06] <kim0> anyone around o/
[15:02] <hazmat> kim0, g'morning
[15:02] <hazmat> or hello is probably more appropriate
[15:30] <kim0> hazmat: hey o/
[15:33] <kim0> team on vacation huh :)
[15:59] <_mup_> ensemble/merged-alt-region-logging r210 committed by<EMAIL_ADDRESS>[15:59] <_mup_> merge ensemble-log-level
[16:00] <_mup_> ensemble/merged-alt-region-logging r211 committed by<EMAIL_ADDRESS>[16:00] <_mup_> merge ensemble-log-crash
[16:07] <jimbaker> kim0, hi
[16:08] <jimbaker> kim0, we have been trying out the alternative region branch. it's not worked for me with deploying our example formulas. you want to give it a try too?
[16:08] <jimbaker> it did work w/ kapil however
[16:16] <kim0> ec2 has recovered it seems .. I'm writing a small user level tutorial now, but if you need someone else to test that branch, sure
[16:17] <jimbaker> kim0, i think it would be useful for sure
[16:17] <jimbaker> it's also a good way to play w/ the environments.yaml file
[16:18] <kim0> jimbaker: cool, any instructions on using that branch ? I'll try it in a few hours though, now right now
[16:20] <kim0> let me know how do I use it, thanks
[16:27] <_mup_> Bug #769030 was filed: Enable one control bucket to be used for multiple regions <Ensemble:New> < https://launchpad.net/bugs/769030 >
[16:29] <jimbaker> you just need to configure two things in your environments.yaml file: region - us-east-1, us-west-1, eu-west-1; and ensemble-branch - https://code.launchpad.net/~hazmat/ensemble/ensemble-alternate-regions
[16:30] <kim0> got it
[16:30] <hazmat> kim0, i also have one with the logging stuff merged in.. lp:~hazmat/ensemble/merged-alt-region-logging
[16:30] <jimbaker> hazmat, sounds good, then we don't use an earlier formula set
[16:30] <jimbaker> have to use
[16:30] <hazmat> jimbaker, it didn't work entirely
[16:31] <hazmat> jimbaker, i'm trying out trunk in east atm to verify the delta
[16:31] <jimbaker> hazmat, sounds good, less mystifying then
[16:31] <jimbaker> we prefer our failures to be consistent ;)
[16:31] <hazmat> jimbaker, what's odd is that the unit relation state in zk (in west) is good, but status isn't reporting it, and wordpress isn't running
[16:32] <hazmat> also ensemble-log seems to return 0 even when it fails/errors.
[16:33] <jimbaker> hazmat, i just got this weird output in a log
[16:33] <jimbaker> 2011-04-22 09:20:52,519 unit:mysql/0: twisted ERROR: TypeError: 'Port' object is not callable
[16:34] <hazmat> jimbaker, can you paste the full log to pastebin
[16:34] <jimbaker> hazmat, will do
[16:34] <hazmat> thanks
[16:35] <jimbaker> http://pastebin.ubuntu.com/597493/
[16:35] <hazmat> jimbaker, is this on the open-port/close-port branches?
[16:36] <jimbaker> hazmat, no, the alternative region branch, running with trunk r200 formulas
[16:36] <jimbaker> i'm going to try the new alt region branch w/ logging merge in now
[16:36] <hazmat> jimbaker, hmm.. there are no port classes in ensemble, only in twisted.
[16:36] <jimbaker> hazmat, indeed
[16:37] <jimbaker> are we sure we got good versions of python, twisted, etc built in these amis?
[16:37] <jimbaker> it's as if we got some version skew going on here
[16:38] <_mup_> Bug #769035 was filed: Need a top level decorataor on all independent callbacks to do nice error printing <Ensemble:New> < https://launchpad.net/bugs/769035 >
[16:39] <hazmat> jimbaker, just stock natty
[16:41] <_mup_> Bug #769036 was filed: Ensemble hook cli api needs to do correct exit codes  <Ensemble:New> < https://launchpad.net/bugs/769036 >
[16:44] <hazmat> jimbaker, so trunk works for me
[16:45] <jimbaker> hazmat, trunk formulas, or using trunk with us-east-1?
[16:45] <hazmat> trunk and us-east-1
[16:45] <hazmat> trying alt-region with us-east-1
[16:46] <hazmat> there's nothing in the branch remotely related to units or hooks..
[16:46] <jimbaker> hazmat, exactly, that's what is so strange here. some other unexpected dependency seemingly
[17:37] <hazmat> jimbaker, the merged-alt-region-logging branch seems to work okay
[17:37] <hazmat> in us-east-1
[17:43] <jimbaker> hazmat, trying it out now
[17:44] <hazmat> jimbaker, cool, i'm trying it out in a different region and then i do see a problem
[17:49] <jimbaker> hazmat, doesn't work for me this try. speaking of round trip overhead, now doing "watch ensemble status" ;)
[17:50] <jimbaker> i had proposed building that in for ensemble status with actual watches, but repeatedly polling like this is the poor man's approach for sure
[17:51] <jimbaker> and the interesting thing is seeing the relation service state disappear... crazy
[17:57] <bcsaller>  jimbaker: the plan with status is to have a mode where it blocks on a topo watch and then reissues the status in a loop
[17:57] <bcsaller> unlike watch it knows when things change
[17:57] <jimbaker> bcsaller, yes, intelligent watches :)
[17:57] <jimbaker> bcsaller, good to know it is in the works
[17:58] <jimbaker> bcsaller, doing "watch ensemble status" is still useful right now
[17:58] <bcsaller> good
[17:59] <jimbaker> i think once we have the relation settings added to ensemble status, that's going to be pretty awesome
[18:42] <hazmat> aha
[18:42] <hazmat> unit agents are dead
[18:43] <jimbaker> hazmat, that would make sense
[18:43] <hazmat> jimbaker, the fact there is nothing in the log is rather frightening
[18:44] <jimbaker> hazmat, indeed. i'm just about to testing us-east-1 w/ trunk at r200, which is the last good one i observed
[18:44] <jimbaker> try testing
[18:45] <hazmat> jimbaker, i was able to get trunk latest from merge-alt-region-logging working on us-east-1
[18:46] <jimbaker> hazmat, i was unable to get that - i was just getting "it works" plus empty relation service states
[18:46] <jimbaker> probably because of dead unit agents
[18:46] <hazmat> jimbaker, no.. i'm actually got populated relation states with dead units agents
[18:46] <jimbaker> hazmat, crazy
[18:46] <hazmat> jimbaker, the variations i'm using are trunk, ensemble-alternate-region, merge-alt-region-logging
[18:47] <hazmat> all with formulas from that are the equivalent of the trunk versions
[18:47] <hazmat> i've seen trunk and merge-alt-region-logging working on us-east-1
[18:47] <jimbaker> hazmat, i have tried all of those, both with us-east-1 and us-west-1
[18:47] <jimbaker> nothing is working end-to-end for me today
[18:48] <jimbaker> everything starts off fine... then it just mysteriously fails
[18:49] <jimbaker> hazmat, maybe i should rebuild my buckets, don't know if that's an issue based on bug 769030
[18:49] <_mup_> Bug #769030: Enable one control bucket to be used for multiple regions <Ensemble:New> < https://launchpad.net/bugs/769030 >
[18:49] <hazmat> jimbaker, yeah.. i switch my buckets when changing regions atm
[18:50] <hazmat> they should recover fine
[18:50] <hazmat> ie. detect dead instance stale file, and create new one
[18:50] <jimbaker> although given how the control bucket works, i wouldn't expect it to impact
[18:50] <hazmat> which is what they normally do, or we'd be cleaning it all the time
[19:00] <jimbaker> bcsaller, hazmat - standup?
[19:00] <hazmat> jimbaker, sounds good
[19:00] <bcsaller> I have little to report, but sure
[19:01] <jimbaker> then it will go fast :)
[19:09] <_mup_> Bug #769120 was filed: Ensemble status shouldn't report dead units based soley on state, but also on presence. <Ensemble:New> < https://launchpad.net/bugs/769120 >
[19:19] <hazmat> http://dtrace.org/blogs/bmc/2010/08/30/dtrace-node-js-and-the-robinson-projection/
[19:20] <hazmat> http://wiki.joyent.com/display/node/Using+Cloud+Analytics
[19:20] <hazmat> http://dtrace.org/blogs/dap/2011/03/01/welcome-to-cloud-analytics/
[19:30] <hazmat> allergies miserable.
[19:39] <jimbaker> hazmat, you really should try hot yoga. i found it really helps clear sinuses and it would seem prevent allergic symptoms too
[20:15] <hazmat> jimbaker, sadly hot yoga isn't my thing
[20:16] <hazmat> does anyone understand apport handling of core files?
[20:28] <hazmat> jimbaker, can you give a hook at this look trivial patch for trunk.. https://pastebin.canonical.com/46611/
[20:28] <hazmat> not sure if argparse version changed, but i currently have these two tests failing for me on trunk
[20:32] <hazmat> bcsaller, ^ if you have a moment and could look at the trivial.. i'm waiting on that before doing some merges.
[20:33] <bcsaller> hazmat: the change to generation happens outside the patch?
[20:33] <hazmat> bcsaller, yeah.. the error output change cause is not clear, i just matched to what the current production is
[20:34] <bcsaller> seems like it should have been caught when the change happend and the tests would have broken.
[20:34] <bcsaller> I'm fine with the change, but want to understand how it happeded
[20:34] <bcsaller> happened
[20:37] <hazmat> bcsaller, yeah.. i'm bisecting the last 5revs now to double check
[20:40] <hazmat> bcsaller, just went back a month history, still getting the errors, i'd have to guess its an argparse change and rev increment
[20:42] <bcsaller> maybe, yeah
[20:43] <bcsaller> thanks for checking
[20:43] <hazmat> bcsaller, seems to be a change between pypi version of argparse and the builtin 2.7 version
[20:43] <bcsaller> ahh, natty on 2.7
[20:43] <bcsaller> makes sense now
[20:45] <hazmat> not sure if that's it.. also happens with python 2.6 using the distro argparse
[20:45] <hazmat> but it does work with the pypi argparse 1.2.1
[20:46] <hazmat> where as the distro version (for 2.6) is 1.1-1
[20:47] <hazmat> no.. actually it didn't work 1.2.1
[20:47] <hazmat> i had used a patched trunk to test that one
[20:48] <_mup_> ensemble/trunk r205 committed by<EMAIL_ADDRESS>[20:48] <_mup_> argparse error output seems to have changed, match tests to match current output [trivial][r=bcsaller]
[20:54] <_mup_> ensemble/trunk r206 committed by<EMAIL_ADDRESS>[20:54] <_mup_> merge ensemble-log-level [a=niemeyer][r=niemeyer][f=767364]
[20:54] <_mup_> This fixes a problem with the ensemble-log hook CLI API,
[20:54] <_mup_> not correctly taking a -lLOG_LEVEL option.
[20:57] <_mup_> ensemble/trunk r207 committed by<EMAIL_ADDRESS>[20:57] <_mup_> merge ensemble-log-crash [a=niemeyer][r=kapil][f=767391]
[20:57] <_mup_> This fixes a traceback when attempting to use the ensemble-log
[20:57] <_mup_> hook CLI API from hooks.
[21:36] <hazmat> jimbaker, the principia trunk seems to work with trunk, but the trunk formulas don't on natty.
[21:44] <hazmat> still seeing unit agents die though
[21:48] <hazmat> hmm
[23:18] <hazmat> jimbaker, txzookeeper unit tests are segfaulting with default natty it appears.
[23:19] <hazmat> jimbaker, bcsaller do you run with the package zk or a local build?
[23:19] <bcsaller> local
[23:20] <hazmat> yeah.. we've been getting away with not having our own packages
[23:20] <hazmat> even though there were known issues with the lucid one, it still worked for our uses.
[23:20] <hazmat> doesn't appear to be the case with natty, we're going to need package trunk (3.4) or backport perhaps
[23:31] <jimbaker> hazmat, curiously i'm reinstalling stuff now
[23:32] <jimbaker> is everyone running on python 2.7 at this point?
[23:32] <hazmat> jimbaker, i am
[23:32] <hazmat> jimbaker, i test with 2.6 occasionally as well
[23:32] <jimbaker> i'm now getting some test errors on trunk, just building a new virtualenv to try 2.7 out
[23:36] <hazmat> jimbaker, what does ./test need in a ZOOKEEPER_PATH ? just the zkServer.sh  script?
[23:36] <jimbaker> hazmat, iirc, it doesn't use zkServer.sh
[23:37] <hazmat> hmm
[23:37] <hazmat> jimbaker, looks like i just need a directory with the jar
[23:38] <jimbaker> hazmat, sounds about right
[23:38] <jimbaker> it looks for both dev and prod installs
[23:38] <jimbaker> which are laid out differently
[23:39] <hazmat> hmm.. yeah.. it doesn't work just pointing to a directory of jars.. which is what the deb does for install into /usr/share/java
[23:39] <jimbaker> makes sense
[23:40] <jimbaker> fortunately easy enough to change in ensemble.tests.common.ManagedZooKeeper
[23:40] <jimbaker> basically a variant of zkServer.sh
[23:40] <jimbaker> was that adjusted in the deb package?
[23:43] <hazmat> jimbaker, just had to fix the test/common get class path to not hardcode src release stuff
[23:44] <hazmat> jimbaker, debian uses /usr/share/java for java libs
[23:44] <jimbaker> which was the whole point of that classpath property, so that's cool


[06:08] <mborzecki> morning
[07:21] <mup> PR snapd#11819 closed: i/b/accounts_service: fix path of introspectable objects <Simple 😃> <Created by mardy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11819>
[07:47] <pstolowski> morning
[08:14] <mvo> pstolowski: good morning!
[08:14] <pstolowski> hey mvo !
[08:42] <mncheck> how do you add a local certificate authority to a snap application such as msteams, skype, or firefox on focal (or jammy or bionic or generally)?
[09:17] <mup> PR snapd#11560 closed: overlord: execute snapshot cleanup in task <Created by mardy> <Merged by mardy> <https://github.com/snapcore/snapd/pull/11560>
[11:12] <mup> PR snapd#11744 closed: secboot: partial reprovision <Run nested> <factory reset 🔌> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/11744>
[11:12] <mup> PR snapd#11786 closed: cmd/snap-confine: mount support cleanups <Created by mardy> <Merged by mardy> <https://github.com/snapcore/snapd/pull/11786>
[12:37] <mup> PR snapd#11823 opened: gadget/install: encrypted system factory reset support <Run nested> <factory reset 🔌> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11823>
[12:47] <mup> PR snapd#11824 opened: Allow editing of Jupyter notebooks in browsers <Created by nteodosio> <https://github.com/snapcore/snapd/pull/11824>
[13:59] <mup> PR snapcraft#3759 opened: extensions: add core22 gnome (rebased) <Created by sergio-costas> <https://github.com/snapcore/snapcraft/pull/3759>
[14:04] <mup> PR snapcraft#3757 closed: Give priority to local environment <Created by sergio-costas> <Closed by sergio-costas> <https://github.com/snapcore/snapcraft/pull/3757>
[14:41] <mardy> golang gurus: is there a more compact way of chaining a string with a "string..."? https://github.com/mardy/snapd/blob/kernel-module-load-dynamic/interfaces/kmod/kmod.go#L30-L31
[14:49] <pstolowski> mardy: i don't think so
[16:59] <mup> PR snapcraft#3758 closed: environment: get LD_LIBRARY_PATH <Created by mr-cal> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3758>
[20:04] <mup> PR snapcraft#3759 closed: extensions: add core22 gnome (rebased) <Created by sergio-costas> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3759>
[20:04] <mup> PR snapcraft#3760 opened: extensions: add core22 gnome <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3760>


[19:02] <Lhademmor>  Can someone please take a look at https://help.ubuntu.com/community/AbiWord ? I don't know enough MoinMoin to see what I've done wrong...
[19:22] <Lhademmor> nvm, i figured it out
[19:22] <mdke> the wiki is so slow today...
[19:23] <sommer> yo, I totally noticed the wiki slowness as well... frustrating
[19:24] <mdke> launchpad has a lot of issues too, possibly it's a general issue
[19:25] <sommer> seems like someone said something last night in #u-devel about doing an update to address either the slowness or some authentication issues
[19:25] <sommer> not 100% sure, wasn't paying much attention... heh
[19:30] <Lhademmor> It would be nice to get an update - also b/c of the additional features, of course..