[21:59] <cjwatson> wgrant: Please have a look at https://code.launchpad.net/~cjwatson/txpkgupload/fix-leak/+merge/247276 as soon as you get a chance; we've had three outages due to memleaks in the last couple of days, and while I don't fully understand why txpkgupload is suddenly so much worse than poppy was (possibly it's just slightly different organisation of the top-level classes causing different amounts of leakage, I'm not sure), this renders it ...
[21:59] <cjwatson> ... stable for me and I'd like to get it rolled out before the weekend
[22:00] <cjwatson> It's not desperately elegant use of Twisted before or after, but I argue it's at least less entirely unidiomatic now :-P
[22:41] <wgrant> cjwatson: How very odd.
[23:00] <blr> wgrant: cjwatson: going to need pygit2 for integration testing this charm, suppose I need to track down the libgit source tarball - do we want the one from jessie or sid?
[23:01] <wgrant> blr: I'd backport the latest libgit2 from sid to the ~launchpad PPA.
[23:03] <blr> wgrant: sounds good. want to have some functional tests for smart-http/ssh and possibly pack frontend/storage
[23:04] <wgrant> blr: We have full end-to-end tests, but calling the git binary itself. It will be useful to be able to eg. inspect the repositories in the tests using libgit2, though.
[23:05] <blr> wgrant: yep of course, but still think there's value in ensuring the services are exposed correctly after deployment
[23:05] <wgrant> Oh, in the charm? Right.
[23:05] <wgrant> Definitely.
[23:05] <wgrant> s/charm/spec/


[01:22] <RAOF> Who wants to help me work out an exciting gmock weirdness? http://paste.ubuntu.com/5615354/ generates http://paste.ubuntu.com/5615358/
[01:39] <duflu> RAOF: Maybe you're missing a .WillOnce(Return(x)); or similar on the end of your EXPECT_CALL(*mock_buffer_factory, create_buffer_rv(_,_,_))
[01:39] <RAOF> Aha! DoOnce overrides the default behaviour, which means that I wasn't returning.
[01:39] <RAOF> duflu: Correct!
[01:39] <duflu> Whee
[01:40] <duflu> Gmock is weird like that. "EXPECT_CALL" does more than expect something. It actually determines the behaviour :P
[01:40] <RAOF> Even worse, while you can WillOnce(DoDefault()), you can't WillOnce(DoAll(Something(), DoDefault())
[01:44] <RAOF> Man, I wonder what clang's error messages would look like.
[01:46] <RAOF> Woot! It compiles!
[01:46] <RAOF> Now, to make it additionally _link_.
[02:08] <RAOF> And only one failing test. Time to heat luncheon pizza.
[03:22]  * duflu is jealous of luncheon pizza
[03:22] <duflu> or generally anyone who can eat regular pizza :/
[05:41] <duflu> RAOF: See also https://bugs.launchpad.net/mir/+bug/1110115
[06:19] <RAOF> Well, that has to be one of the stupider reasons for failing a test: asserting the expectations *after* the call that satisfies them.
[06:19] <RAOF> BAH
[06:49] <duflu> RAOF: Asynchronous expectations! <insert poorly informed quantum mechanics joke>
[06:52] <tvoss> RAOF, happens to all of us :)
[07:41] <tvoss> mmrazik, ping
[07:41] <mmrazik> tvoss: pong
[07:41] <tvoss> mmrazik, http://unity.ubuntu.com/mir/ is accessible now, can you adjust the jobs or do we need thomi for that?
[07:42] <mmrazik> tvoss: I should be able to do it. Is there any info from the ticket (like what user to use to scp)?
[07:42] <mmrazik> let me check the autopilot job to see what I need
[07:42] <tvoss> mmrazik, don't know :)
[07:43] <mmrazik> tvoss: mhm... I guess we will need to figure out. Autopilot is using autopilot-sync.. so let me first try to guess mir-sync
[07:45] <mmrazik> tvoss: I guess I'm out of luck. In matter of fact it looks like autopilot-sync stopped to work too (permission denied)
[07:45] <mmrazik> tvoss: do you have the ticket # at hand?
[07:48] <tvoss> mmrazik, forwarded you the mail
[07:51] <RAOF> Macros like EXPECT_THROW: measurably worse than Hitler. :(
[07:52] <RAOF> It couldn't possibly say “you've removed the header that was implicitly including <stdexcept>, so I now don't know what std::logic_error is”. Oh, no.
[08:01] <duflu> RAOF: I have clang building Mir now. It's messy and needs some cleaning up yet
[08:01] <RAOF> Woot!
[08:01] <duflu> But the errors are phenomenally better than gcc
[08:02] <duflu> And numerous :P
[08:02] <RAOF> And we'll always have the jenkins autotests to tell us when we've used something that doesn't work in gcc :)
[08:48] <tvoss> mmrazik, any luck with the mir-sync stuff?
[08:48] <mmrazik> tvoss: nope. I was on a call
[08:48] <tvoss> mmrazik, ack
[08:48] <mmrazik> tvoss: and I think there is something broken even for autopilot
[08:52] <mmrazik> tvoss: it looks like few bytes are transfered and then the connection is lost
[08:52] <mmrazik> tvoss: will need to follow up on #is
[08:52] <tvoss> mmrazik, thx
[08:52] <tvoss> mmrazik, can you cc me on the ticket please?
[08:54] <mmrazik> tvoss: I'm just trying irc first
[08:56] <tvoss> mmrazik, ack
[08:57] <mmrazik> tvoss: btw. what should be actually copied? /usr/share/doc/mir-doc/html/* ?
[09:13] <tvoss> mmrazik, yup
[09:26] <alf_> duflu: alan_g: @surface-types, configure() at RPC level, I understand your concern about the pain of adding new RPC methods. My suggestion was based on having a limited and relatively stable number of surface attributes. Is this not the case?
[09:27] <duflu> alf_: It's not the case right now. I will have a couple soon and keep thinking of more such attributes that clients will eventually need to be able to set
[09:27] <alan_g> alf_: duflu even if we multiplex different data over an rpc call we can demultiplex at the server boundary
[09:28] <alan_g> It doesn't have to propagate frontend => shell => surfacers
[09:28] <duflu> alan_g: If you do it too close to the boundary (frontend) then same problem. Too many classes will be changing all the time
[09:29] <duflu> alan_g: If you think you can safely move the boundary without cursing future development to extraneous effort then I suggest proposing a proof of concept branch
[09:30] <alan_g> duflu: well, I was answering alf_ - you know I don't think these attributes should ever go beyond shell anyway
[09:31] <duflu> alan_g: Most other attributes have to. For example "state" changes the server into an "unredirected" rendering mode for example.
[09:31] <duflu> And "hidden" directly affects a surfaces::Surface
[09:31] <duflu> It's only "type" that can stop at the shell layer
[09:32] <alan_g> duflu: "hidden" maps to Surface::hide()/show()
[09:32] <alan_g> And that can happen by shell decoding an attribute
[09:33] <duflu> alan_g: Consider also width/height. Attributes or not, such messages from the client will end up reaching surfaces::Surface
[09:33] <alan_g> duflu: but not as shell related attributes (I believe)
[09:33] <mmrazik> tvoss: srry... one more question... do you want http://unity.ubuntu.com/mir or http://unity.ubuntu.com/mir/api asi thomi was suggesting (the later requires some mkdir-ing for me and moving things aournd; but not a big deal)
[09:34] <alan_g> mmrazik: http://unity.ubuntu.com/mir
[09:34]  * mmrazik is just uploading stuff to http://unity.ubuntu/mir/
[09:34] <tvoss> alf_, ^ any thoughts?
[09:35] <alf_> alan_g: duflu: I think I would prefer to do the demultiplexing in the Mediator, the attrib,value pair (or any other method we use) is a communications detail that may change, not need to propagate it further down
[09:35] <duflu> I really wish people raised these concerns 2 weeks ago...
[09:35] <alan_g> alf_: I'm not so sure - I think the shell is what interprets attributes
[09:35] <duflu> Please put your comments in the merge proposal so I can review them next week
[09:36] <alan_g> duflu: I wish we'd discussed the design before the MP appearede
[09:36] <alf_> tvoss: mmrazik: Yes, http://unity.ubuntu.com/mir is good as we have a main page
[09:36] <duflu> alan_g: Too much room for misunderstanding in English. C++ is clearer :)
[09:37] <alan_g> duflu: more precise, not necessarily clearer
[09:37] <alan_g> duflu: I have design discussions with everyone else on the team. It works for us.
[09:38] <alan_g> duflu: alf_ does too
[09:38] <duflu> alan_g: Yes we can and do discuss a lot. But some/most problems and disagreements are not foreseeable.
[09:39] <alan_g> duflu: some are not. some are easily prevented.
[09:39] <duflu> Please put your concerns in the merge proposal. I really don't want arguments ruining my weekend
[09:40] <alan_g> duflu: let's try a either a hangout or pair-programming when you're back. MP/review isn't working - it is just frustrating.
[09:40] <duflu> alan_g: Although I suggest waiting until there are multiple attributes and then decide if we're demuxing in the right location
[09:41] <alan_g> duflu: I agree with that bit
[09:41] <duflu> MP/review works very well. It's formal and clearly documented. Unlike IRC where you lost track of a conversation
[09:41] <duflu> -lost +lose
[09:42] <alan_g> duflu: your idea of working is "I've now been working on this branch for a month and it's been under review for two weeks. It has worked perfectly without bugs for the entire duration. Remember we're only arguing about style issues that can be fixed later."
[09:42] <mmrazik> tvoss et al: Enjoy: http://unity.ubuntu.com/mir/ !
[09:42] <tvoss> mmrazik, thanks :)
[09:42] <alan_g> mmrazik: \o/
[09:42] <duflu> alan_g: I am happy to address all your concerns in the formal environment of a merge proposal. My frustrations aside, let's use Launchpad as intended
[09:43]  * alan_g shrugs
[09:43] <duflu> Forgive me. But if any further code change is required along the lines of what's being discussed then it's much too large for me to do in the few minutes I have left
[09:45] <alan_g> duflu: I don't expect a rewrite in a few minutes, just something different in the next two weeks
[09:48] <alan_g> duflu: have a good weekend! "See" you next week.
[09:50] <duflu> alan_g: If you have a solid suggestion and the time, please propose a branch to mine. Keep in mind we don't want per-attribute interfaces leaking into the reporting system, amongst other things
[09:50] <alan_g> duflu: ack
[09:52] <alf_> duflu: alan_g: @solid suggestion, I think too many conflicting solid suggestions are delaying us here, instead of a discussion through which we can find reasonable compromises
[09:53] <alf_> duflu: alan_g: problem is that the communication latency for MPs and launchpad is very high, thus the need for more direct communication
[09:54] <alan_g> alf_: I'm all for discussion - I'd rather have a half hour conversation than spend a day recoding
[09:54]  * tvoss paints on the wall: Be reasonable, agile and "Done is better than perfect"
[09:55] <alan_g> alf_: as you've more overlap time with duflu than I have, how about you try pair programming with him when he gets back?
[09:56] <duflu> alan_g, alf_: We're all perfectly capable of communicating in writing. And I have addressed every concern raised so far. If you have more concerns, please put them in writing and I'll work to resolve them as always
[09:57] <duflu> The greatest hurdle so far has been trying to understand the design rationale for much of the Mir code, but I believe I'm making good progress in understanding the intention of what's there...
[10:01] <duflu> tvoss: Yes we do seem to iterate a lot in seek of perfection. Although that's often feasible, it is harder with differing views of "perfection" :)
[10:01] <duflu> Umm, "in search of"
[10:02] <tvoss> duflu, I'm just saying that perfection is the enemy of good enough, and alf_ was pointing out that compromises might be a better way to move forward and achieve clarity
[10:03] <alf_> alan_g: duflu: sure, but I think I prefer a three-way discussion at this point (since all three of us have differing opinions at this point)
[10:04] <alan_g> and I'm saying a "face-to-face" conversation is the best way to refine a resolution
[10:04] <alan_g> alf_: I'm sure I could live with anything you and duflu are both happy with.
[10:05] <duflu> alan_g: That may well be true. But it's not feasible on the weekend. We'll save some time if you write down ideas for what you think needs to change and I can have something ready before you wake up on Tue.
[10:09] <alan_g> duflu: could you also see if you can get hangouts set up - for if we still need to talk.
[10:09] <duflu> alan_g: That's feasible. It used to work fine with 2 people. Just died with more :P
[10:10] <alf_> duflu: do you have the latest binaries from google?
[10:11] <duflu> alf_: Probably not
[10:12] <alf_> duflu: what happens for me is that every once in a while hangouts break in some way, and upgrading the binaries usually improves the situation
[10:14] <alf_> alan_g: duflu:  @"Although I suggest waiting until there are multiple attributes and then decide if we're demuxing in the right location", so let's merge what we have and refactor later ?
[10:16] <alan_g> alf_: I don't think that's the blocker. Let me review the latest version.
[10:20] <duflu> alf_: I was thinking the same, but thought it would be rude of me as author to suggest it
[10:20] <duflu> Especially as I am willing to make changes myself and am willing to do all the work still
[10:26] <duflu> Here, have clang support.
[10:27] <duflu> And happy (grand prix) weekend :)
[10:27] <alf_> duflu: have fun!
[11:21] <alan_g> alf_: had a chance to look at https://code.launchpad.net/~alan-griffiths/mir/refactor-frontend-cleanup/+merge/153386 yet?
[11:21] <alf_> alan_g: not yet, will do shortly
[11:59] <alf_> alan_g: commented
[12:00] <alan_g> alf_: looking...
[12:04] <tvoss> alan_g, alf_ can you give https://wiki.ubuntu.com/Mir/GetInvolved a spin? Feel free to edit in place
[12:07] <alf_> tvoss: sure, so what's the plan with wiki + project-page coexistence?
[12:08] <tvoss> alf_, we can have both, but I want to have a simple landing page where people are welcomed and introduced to the project
[12:09] <tvoss> alf_, that page should be quite static and dispatch to the up-to-date documentation as generated from the source tree
[12:09] <tvoss> makes sense?
[12:10] <alf_> tvoss: Sounds good. Any luck finding a better theme for the doxygen docs?
[12:10] <alf_> tvoss: or perhaps asking design for one...
[12:28] <tvoss> alf_, not yet
[15:15] <kdub> morning folks! status, ported over the android framebuffer type (lessening hybris dependency, solving some alloc issues), working on android display selection
[15:18] <alan_g> kdub: morning. Don't forget to review a few MPs
[15:19] <tvoss> morning kdub
[15:19] <alan_g> status: unblocked glog, Proposed refactorings we've discussed.
[15:26] <kdub> alan_g, i might have to ping someone to get libgoogle-glog0 into quantal
[15:26] <alan_g> kdub: quantal?
[15:27] <kdub> phablet builds are still quantal, last I downloaded :)
[15:27] <kdub> i don't think we have to block the glog branch on it
[15:27] <kdub> rsalveti, are the phablet builds still quantal? i heard rumblings about transitioning to raring
[15:28] <tvoss> kdub, glog should be in universe in quantal iirc
[15:28] <rsalveti> kdub: still quantal, raring transition kind of going in place
[15:28] <kdub> thanks
[15:29] <kdub> rsalveti, while i've bothered you... here's how i get the demo to run with mir underneath... lp:~kdub/aal+/ubuntu-platform-mir
[15:31] <rsalveti> lemme see
[16:30] <alan_g> kdub: re add-glog-logging - is there anything I need do, or are you handling it.
[16:30] <kdub> alan_g, i'll handle it
[16:30] <alan_g> kdub: cool
[16:34] <alf_> alan_g: @add-glog-logging, do we need to make it explicit to the users that we are using glog? I would think this is an implementation detail.
[16:35] <alf_> alan_g: (mostly referring to the command line options)
[16:36] <alan_g> alf_: Probably not, but I'd prefer to address that when we've covered some other reporting scenarios
[16:38] <alf_> alan_g: I am fine with that (i.e. that there is the prospect of hiding the details)
[17:16] <alan_g> kdub: want to review refactor-frontend-cleanup before I decide to land it?
[17:17] <kdub> alan_g, let me scan it for red flags... 5 minutes :)
[17:17] <kdub> lots of branches lately! :)
[17:18] <alan_g> kdub: I want them all to land before the weekend, so we can have a good start next week.
[17:19] <racarr> alan_g: Removed the .orig here https://code.launchpad.net/~robertcarr/mir/prepare-shell-for-input-focus/+merge/153483
[17:19] <racarr> if you have time to take a look another look
[17:20] <alan_g> racarr: looking...
[17:20] <kdub> alan_g, +1'd. lots of sed :)
[17:21] <alan_g> kdub: you know my secret!
[17:21] <racarr> alan_g: Thanks
[17:21] <racarr> not sure what to do with prepare-to-send-clients-input will talk to daniel my afternoon
[17:21] <racarr> oh no I wont its his saturday
[17:23] <racarr> fixed header here https://code.launchpad.net/~rocket-scientists/mir/prepare-for-inprocess-egl-clients/+merge/150379 as well
[17:25] <kgunn> kdub: thanks for unblocking alf
[17:26] <kgunn> understand its still an open task
[17:26] <alan_g> racarr: I think you get what votes you can and then take this as advice: https://code.launchpad.net/~robertcarr/mir/prepare-to-send-clients-input/+merge/152100/comments/333969
[17:27] <alan_g> kgunn: are you able to give an opinion? (Read the comments) https://code.launchpad.net/~robertcarr/mir/prepare-to-send-clients-input/+merge/152100
[17:27] <alan_g> racarr: approved
[17:27] <kgunn> ^ reading
[17:30] <alan_g> alf_: racarr any review comments for https://code.launchpad.net/~alan-griffiths/mir/refactor-surfaces-cleanup/+merge/153431 ?
[17:36] <alf_> alan_g: why does surfaces need a deleter ctor parameter?
[17:38] <alan_g> alf_: It inherits two use cases - one with a null deleter and one that deletes from the surface stack. I didn't feel it should be fixed by this MP but could be pursuaded
[17:39] <racarr> thinking about refactor-surfaces-cleanup
[17:40] <racarr> as for the multi channel stuff..I dunno I actually have the impression that some issues
[17:40] <racarr> are easier to solve with split channels and timestamps
[17:40] <racarr> and Ir emember I came to this conclusion when reading the why X is not our ideal windowing system paper in Lexington
[17:40] <racarr> but I can't remember why
[17:40] <racarr> so I will try and read it again and come back :)
[17:42] <racarr> Hmm
[17:42] <racarr> i think the deleter is fine
[17:43] <racarr> except at 510-512 and 524-526 it seems kind of strange
[17:43] <racarr> because the contents of the deleter are in the test
[17:44] <racarr> so if the implementation is modified to not pass a surface_stack.destroy_surface deleter
[17:44] <racarr> the test still passes right?
[17:44] <racarr> alan_g: ^
[17:44] <racarr> So maybe there should be like
[17:44] <racarr> static msh::Surface::create_within(surface_stack, params)
[17:47] <alan_g> racarr: I guess another option would be to provide a Deleter class. Or to rework the interaction between shell and surfaces.
[17:49] <alan_g> mmrazik: jenkins problem? "/tmp/cckobwIf.s: Fatal error: can't close CMakeFiles/unit-tests.dir/graphics/test_gl_renderer.cpp.o: No space left on device"
[17:49] <mmrazik> alan_g: just added a comment and reapproved
[17:49] <mmrazik> alan_g: but to answer your question -- yes, jenkins problem
[17:50] <alan_g> mmrazik: thanks
[17:52] <kdub> kgunn, no problem. i forgot to mention, but in that blueprint, i almost see 'display integration' as 'vsync timings + display mode selection'
[17:52] <kdub> i guess we can leave it there for now
[17:52] <kgunn> kdub: feel free to reword
[17:52] <kgunn> no prob
[17:53] <racarr> alan_g: Hmm. I am not sure. A deleter class doesn't sound particularly compelling
[17:54] <alan_g> racarr: In that case I prefer to untangle the shell/surfaces interaction. Either in this MP or a future one.
[17:55] <racarr> I am not sure I see how to do it right now...
[17:56] <alan_g> racarr: it isn't obvious to me now. But I'm sure after a bit of thought it will simple.
[17:57] <racarr> another thought, which is kind of similar to a deleter class but slightly more appealing to me
[17:57] <racarr> or maybe this is what you meant...
[17:58] <racarr> is like SurfaceController implements...SurfaceOwner? or something, with destroy surface
[17:58] <racarr> so the call .destroy_surfaces moves to shell::Surface dtor
[17:59] <racarr> because the only case for a null deleter is in tests right?
[17:59] <racarr> So they should just supply a stub
[17:59] <racarr> maybe even just ignore the additional interface.
[18:00] <alan_g> racarr: Part of fixing it is to work out what we really need from those tests.
[18:01] <racarr> that is why I liked
[18:01] <racarr> the static method, because then you can express what we want from both of those tests now with one idea..i.e.
[18:01] <racarr> TEST(Surface, create_with_returns_surface_managed_through_controller)
[18:01] <racarr> or something
[18:02] <racarr> which I think sounds like what we want
[18:03] <racarr> the @ makes me feel like I am yelling
[18:03] <alan_g> racarr: It needs more cleanup in that area anyway - the shell shouldn't be updating the SurfaceStackModel directly. So I guess I'll rework on Monday
[18:04] <racarr> Hmm ok.
[18:04] <alan_g> Is my EOD so I'll try to forget it for the weekend.
[18:04] <racarr> I am thinking though, the current branch
[18:04] <racarr> I don't know if it's any worse and the naming is definitely better
[18:05] <alan_g> Fine. Land it and I'll propose rework MP on Monday. (Unless you do it today)
[18:05] <racarr> Ok. Sounds good
[18:06] <racarr> I probably wont today unless I have any ideas
[18:06] <Cheery> how are the Mir-nvidia -negotiations going on?
[18:06] <racarr> I generated a big list of minor little refactorings yesterday
[18:06] <racarr> that I want to get through once
[18:06] <racarr> the risk of conflicts is a little lower
[18:06] <alan_g> Is it ever?
[18:06] <Cheery> http://hardware.slashdot.org/story/13/03/15/1254210/nvidia-walked-away-from-ps4-hardware-negotiations
[18:06] <racarr> eh
[18:06] <Cheery> that is particularly interesting
[18:06] <racarr> friday afternoon I should be safe from
[18:06] <racarr> too much
[18:08] <racarr> alan_g: Ok well have a good weekend!
[18:08] <alan_g> racarr: In that case, land as much as you can this morning.
[18:09] <alan_g|life> Cheery: I don't know anything to tell you
[18:10] <Cheery> alan_g|life: why is it important, should you know it?
[18:11] <Cheery> I mean I'd have understood "I can't tell you"
[18:11] <racarr> Cheery: re: nvidia.
[18:11] <racarr> I think "well" is the best answer I can give right now ;)
[18:13] <Cheery> I sort of see nvidia is probably getting to this. but I'd like to know when it happens.
[18:14] <Cheery> it'd be nice to know if it goes public in 10 days or in 2 months, or by the end of this year.. or...
[18:18] <racarr> :)
[18:18] <racarr> It's all based on the phases of the moon and alignments of the planets
[18:19] <Cheery> easy stuff then.
[18:31] <racarr> hehe
[18:33] <racarr> alf_: kdub: Can we wait to turn
[18:33] <racarr> refactor-surfaces-cleanup to approved until after I land
[18:33] <racarr> prepare-to-send-clients input
[18:33] <racarr> p.s. do either of you want to review that
[18:34] <racarr> I will sort out the conflicts either way but I think it will be less conflicts this way
[18:34] <racarr> alf_: Oh and could you look
[18:34] <kdub> racarr, thats fine by me
[18:34] <racarr> at prepare-for-inprocess-egl-clients agian?
[18:34] <racarr> your last comment is the dissaprove from before we decided to remove those tests
[18:34] <racarr> kdub: Thanks :)
[18:35] <racarr> XD next week all my branches get to be like send-clients-input inprocess-egl-clients, etc...I wonder if the week after that it will just be
[18:35] <racarr> prepare-to-refactor-sending-clients-input
[18:35] <racarr> and I get stuck in a loop
[18:36] <kgunn> racarr: alan_g|life got waylayed by mgmt discusion
[18:36] <kgunn> racarr: i read duflus comment
[18:37] <kgunn> i tend to agree about the secondary channel
[18:37] <kgunn> but i don't why you couldn't just use a surf id like he suggested
[18:38] <racarr> Because the android code is nontrivially dependent on (through leaky abstraction Is uppose)
[18:38] <racarr> and implements
[18:38] <racarr> the secondary channel method
[18:39] <racarr> so to do it now, sets back progress a week or so
[18:39] <racarr> which in the face of not really seeing the concrete problem I am not so disposed to do
[18:39] <racarr> and I am inclined to think that android had a pretty good reason for structuring it the way they do now
[18:39] <kgunn> racarr: don't get me wrong
[18:40] <racarr> for example a client with an input thread and a display thread, display thread will be at most at say 60hz but input thread is easily processing events at 120 hz
[18:40] <kgunn> i think duflu was pointing out potential race conditions that are legit
[18:40] <racarr> so the display thread.
[18:40] <kgunn> but solvable with the id
[18:40] <racarr> is hung up on synchronously on rendering which is fine because it can go a little slow
[18:41] <racarr> but the input thread should still be able to handle events at a fast rate, because it's a two way negotiation with the server (i.e. the client has to explicitly handle-or-not-handle events)
[18:41] <racarr> and if the client falls behind events start to become batched and then interpolated
[18:41] <racarr> I dunno I have the idea that on the seperate channel with the idea of a dedicated input receiver thread
[18:42] <racarr> we will have more predictable performance characteristics
[18:42] <kgunn> ironically one of the unity guys was having this exact race condition problem with a test on autopilot
[18:42] <kgunn> click was for a button(surface) that wasn't present
[18:43] <kgunn> so click got lost
[18:43] <racarr> In X though it's hard to do the synchronization
[18:43] <racarr> based on just comparing timestamps or something because
[18:44] <racarr> it's a three way race between the client the compositor/window manager and the server
[18:44] <racarr> I am just thinking about daniel's example...
[18:44] <racarr> I had convinced myself yesterday it would work fine but let me think again before I say something dumb :p
[18:44] <tvoss> racarr, ping
[18:44] <racarr> tvoss: Pong!
[18:45] <racarr> I didn't do it
[18:45] <racarr> I promise
[18:48] <racarr> I mean, so an input event is in the dispatcher.
[18:48] <racarr> the dispatcher looks at a snapshot or locked view of the surface stack and says
[18:49] <racarr> ok B is on top so I send it to B
[18:49] <racarr> then B closes inbetween that
[18:49] <racarr> decision and B handling
[18:49] <racarr> the event
[18:49] <racarr> how is it that A gets the events that were targeted at B?
[18:51] <racarr> I mean it doesn't
[18:51] <tvoss> racarr, it cannot happen as changes to the surface stack is transactional
[18:51] <racarr> That's what I think :)
[18:51] <tvoss> the worst thing that can happen is that B receives an event for a surface that does not exist anymore
[18:51] <racarr> in fact, it's even better than that. You can then go once you are notified that B did not respond
[18:51] <tvoss> but that's fine from, the behavior is consistent from the server's perspective
[18:51] <racarr> you can look at the timestamp
[18:51] <racarr> err...
[18:52] <racarr> ok nvm this isn't fully coherent yet
[18:52] <racarr> I think there are some cases where you might want to redispatch to A
[18:52] <racarr> would be like the "pixel perfect behavior"
[18:52] <racarr> I'm not sure
[18:52] <racarr> but the worst case is yeah, this B receives an event but the surface doesn't exist
[18:52] <racarr> no one receives events they shouldn't
[18:52] <racarr> well, from other surfaces*
[18:52] <racarr> *shrug*
[19:03] <kgunn> racarr: ....i'm tempted to say cool
[19:03] <kgunn> racarr: lunatic fringe question....what about B has 2 surfaces...1 disappears?
[19:04] <kgunn> could B be fooled into handling event for surface 2 when it was meant for surface 1 ?
[19:04] <tvoss> kgunn, an event is always targeted towards a surface
[19:04] <racarr> no because it's a seperate
[19:04] <racarr> channel per surface not per client
[19:04] <kgunn> ah
[19:04] <kgunn> then "cool"
[19:06] <kgunn> racarr: tvoss so duflu was on crack from the beginning :)
[19:06] <tvoss> kgunn, duflu might have a valid point, but we will find out and then we iterate
[19:06] <racarr> It's definitely a concern (even if I don't think this race scenario is)
[19:06]  * tvoss paints "perfection is a journey, not a destination" on the channel wall
[19:07] <racarr> but there are more complex cases like menus, etc.
[19:07] <racarr> that I don't fully understand yet.
[19:07] <kgunn> i guess the base question is...why would a surface go away
[19:08] <kgunn> that'll determine what you'd do with the input
[19:08] <racarr> I think while two channels sounds like a lot more potential for racing...
[19:08] <racarr> my thought is that, if you have two seperate channels of control, one handling display messages all with valid timestamps, and one handling input messages all with valid timestamps, and all changes to the surface stack are transactional
[19:09] <racarr> I unno
[19:09] <racarr> I can't imagine a race right now
[19:09] <tvoss> racarr, just go ahead and let's complete one iteration :)
[19:09] <racarr> its because the removal of
[19:09] <racarr> the surface and the change of focus
[19:09] <racarr> is a transactional operation
[19:09] <racarr> as opposed to in X where it has to go through the window manager
[19:10] <racarr> and becomes another race point
[19:10] <kgunn> racarr: i think tvoss is right
[19:10] <kgunn> implement
[19:10] <racarr> *shrug*
[19:10] <racarr> ITERATION 1 GO!
[19:10] <kgunn> and then tweak frequencies if you want
[19:10] <racarr> *nods*
[19:10] <kgunn> and see if you can generate one
[19:10] <kgunn> a race that it
[19:10] <kgunn> damn/it/is
[19:11] <racarr> ok I am changing prepare-to-send-clients-input to approved then
[19:11] <racarr> and https://code.launchpad.net/~robertcarr/mir/prepare-shell-for-input-focus/+merge/153483
[19:11] <racarr> (thanks for review btw kdub :))
[19:12] <kdub> racarr, sure!
[21:09] <racarr> kgunn: Reading your weekly update
[21:09] <racarr> wonder if we should send weekly updates to
[21:09] <racarr> public list as well?
[21:15] <kgunn> racarr: yeah, good idea
[21:15] <kgunn> you mean mir-devel
[21:15] <kgunn> ?
[21:15] <poseidon> Anybody here set up mir on archlinux?
[21:22] <racarr> kgunn: Yes
[22:29] <racarr> More merge conflicts! Wheeeeeeeeeeeeee


[00:27] <DS-McGuire> AkivaAvraham, Are you okay with everything in the sub?
[00:28] <AkivaAvraham> DS-McGuire, yep; looks fine to me :)
[00:28] <AkivaAvraham> you?
[00:29] <DS-McGuire> Awesome, yeah everything is fine. I was just checking :)
[00:29] <AkivaAvraham> DS-McGuire, I think it actually looks quite nice tbh
[00:30] <DS-McGuire> AkivaAvraham, Wish we had more stuff going on though, but I guess that will come in time. Yeah I agree, styling it to fit with the Ubuntu design just makes it look awesome!
[00:31] <AkivaAvraham> :)
[01:23] <diego7319> Hi
[05:28] <X_o> I have this error can someone give a idea how to fix it thx >>>> 00:27:18: Could not start process ""  Error while building/deploying project B_p_Proj (kit: UbuntuSDK for i386 (GCC ubuntu-sdk-14.10-utopic)) When executing step 'Make'
[06:34] <X_o> kit: UbuntuSDK for i386 (GCC ubuntu-sdk-14.10-utopic)) When executing step 'Make'
[13:54] <Mulklouv> hi!
[13:54] <Mulklouv> hum why Ubuntu Sdk don't detect the device emulator?
[13:55] <Mulklouv> I don't find it in "Ubuntu Devices" but I see it in "Log".
[13:58] <Mulklouv> in log I've that: Detecting device.. Checking installed emulator package. ii ubuntu-emulator 0.4+14.10.20141002-0ubuntu1
[13:58] <Mulklouv> but I don't find this in "Ubuntu Devices"
[15:18] <Grown> Hello,
[15:18] <Grown> I should use i386 or arm for emulator?
[16:12] <Grown> I, I've installed ubuntu touch emulator but I've an issue
[16:12] <Grown> my screen is too small
[16:12] <Grown> I can't see the entiere emulator
[16:12] <Grown> How resize?
[16:13] <DanChapman> Grown: you can change the scaling from the devices tab in QtCreator.
[16:14] <Grown> ok, well, but where?
[16:14] <Grown> I don't find it
[16:15] <DanChapman> Grown are you running it from terminal or QtCreator?
[16:18] <Grown> qtcreator
[16:20] <DanChapman> Grown: did you follow this tutorial? http://developer.ubuntu.com/en/apps/sdk/tutorials/using-the-ubuntu-emulator/
[16:20] <Grown> nope, thanks!
[16:20] <DanChapman> Grown: yw
[17:31] <Guest20596> I'm trying to set up a project for an "app with QML extension library" but at the end of the setup process, I'm prompted to manually locate the cmake executable with the message "no cmake executable was found in the path"
[17:32] <Guest20596> Do I have to manually install something?
[19:13] <Guest20596> I don't necessarily even want to make a project like this.  What I actually want to do is just take the QML project that I've got now and run a system command
[19:13] <Guest20596> But apparently in order to do that I've got to make a new project


[02:30] <mpt> Gooooooooooooooooooooood afternoon Launchpadders!
[02:35] <kiko-zzz> hello mpt
[02:35] <kiko-zzz> I'm the zzz man
[02:39] <jordi> zzz
[02:39] <jordi> dude
[02:39] <jordi> I'm going to be zzz tomorrow
[02:42] <kiko-zzz> I'm sending pqm patches
[02:44] <mpt> kiko-zzz, this bug importance work is sending me dangerously close to learning about SQL*Join
[02:47] <kiko-zzz> really? I wonder why
[02:52] <mpt> because now that I've fixed the DB classes to default to sorting by importance rather than by severity then priority, the list of bugs reported by X is returning bugs reported by other people too
[02:53] <mpt> it's probably just a silly mistake of mine somewhere
[02:53] <mpt> meanwhile, "Failed to load application: No module named conch.ssh"
[02:53] <spiv> mpt: you need a sourcecode/twisted directory
[02:54] <mpt> ah, thanks
[02:54] <mpt> how recent is that?
[02:54] <spiv> Since about half-way through the sprint :)
[02:57] <mpt> hmm, I've merged rocketfuel since then
[02:57] <mpt> Odd it didn't get copied in
[03:00] <spiv> Well, merging rocketfuel would have merged in the need for it, but like other sourcecode/* things, it's a seperate branch.
[03:00] <mpt> ah
[03:00] <mpt> hence the occasional need to cd sourcecode/whatever; bzr pull; cd ../..
[03:00] <spiv> Yep.
[03:01] <mpt> wow, some tests are passing now
[03:01] <spiv> Heh :)
[03:09] <dilys> Merge to devel/launchpad/: [r=fabbione,radix (what a man has to do to land a patch on a saturday)]  Fix for bug #3910: Sorting +specs table doesn't work. Allows specifying sortkey/revsortkey inside a <td> and handle that in the JS sorting code; cleans up templates that provide sortkeys. Some gratuitous cleaning up and detabifying as I go. (r3381: kiko)
[03:10] <radix> woot, I'm famous
[03:19] <mpt> It's not Saturday!
[03:19] <lifeless> it could be
[03:25] <spiv> Hmm, the runmirror cron script seems to be badly broken.
[03:26] <lifeless> thats the baz 1 one
[03:26] <lifeless> yes ?
[03:27] <spiv> lifeless: I have no idea, I just see it's sending an error report every time it runs :)
[03:28] <lifeless> hmm, maybe my lperrors subscription dies
[03:28] <lifeless> last I have is nov 11
[03:28] <lifeless> got an archive url for me? or forward me one ?
[03:29] <spiv> lifeless: https://lists.ubuntu.com/mailman/private/launchpad-error-reports/Week-of-Mon-20060403/024989.html
[03:29] <spiv> lifeless: It's alternating with rosetta-poimport.py at the moment, just take a peek at the archives...
[03:30] <spiv> (I'm glad I subscribe to error reports digests!)
[03:30] <lifeless> thats the bzr on
[03:30] <lifeless> *one*
[03:31] <lifeless> do you have time to peek at this ?
[03:31] <lifeless> its almost certainly crap data coming out of the branches-to-pull.txt page
[03:31] <lifeless> such as a URL with spaces in it
[03:32] <lifeless> I'll do a cherry pick for a fix.
[03:41] <lifeless> spiv: ping
[03:42] <spiv> lifeless: Ok, I'll look.
[03:42] <spiv> lifeless: Although...
[03:42] <lifeless> spiv: thanks. You know the url ?
[03:43] <spiv> lifeless: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-04-01/A1
[03:43] <spiv> lifeless: There's a heap of those in the last lp error summary
[03:43] <lifeless> hah
[03:43] <lifeless> well thats the fault then
[03:43] <spiv> lifeless: So maybe runmirror is choking on the error page :)
[03:44] <lifeless> indeed
[03:44] <spiv> lifeless: Ah, presumably my change to the config values somehow broke the config being used.
[03:45] <lifeless> looking
[03:46] <lifeless> its missing the supermirrorsftp section in launchpad.conf in configs/production1/launchpad.conf
[03:46] <lifeless> can you add that ? rs=lifeless
[03:49] <lifeless> ok that should be sorted
[03:51] <spiv> Ok, I think the cron job is on a 10 minute interval, so we should find out if it worked pretty quickly.
[03:53] <spiv> lifeless: Just to production1?
[03:53] <lifeless> yep
[03:53] <spiv> Ok.
[03:53] <lifeless> only production1 offers the internal pages for this
[03:53] <spiv> Ah.
[04:12] <spiv> lifeless: Well, there are no new error reports from runmirror, so I guess it worked.
[04:12] <spiv> lifeless: Thanks
[04:12] <lifeless> np
[04:12] <lifeless> thank you for spotting it
[04:18] <radix> thanks guys :-)
[04:34] <dilys> Merge to devel/launchpad/: [rs=lifeless]  Add missing supermirrorsftp section to configs/production1/launchpad.conf, fixing http://gangotri.ubuntu.com:9000/supermirror-pull-list.txt. (r3382: Andrew Bennetts)
[04:50] <mpt> actually, make check_merge output in general
[05:16] <stub> Probably me forgetting that 'print foo,' inserts a space and I should have used 'sys.stdout.write(foo)'
[05:19] <mpt> stub, it's in random places like the middle of a "[05:20] <stub> mpt: Yup. Probably every 1024 characters if you can be bothered counting ;)
[05:20] <stub> I'll commit a fix.
[05:23] <lifeless> stub: what did you do ?
[05:23] <stub> print foo,
[05:24] <lifeless> stub: I meant where :).
[05:24] <spiv> lifeless: test_on_merge.py
[05:24] <spiv>             chunk = os.read(proc.stdout.fileno(), 1024)
[05:24] <spiv>             print chunk,
[05:25] <lifeless> spiv: ah the incremental output foo
[05:25] <spiv> lifeless: Right.
[05:25] <lifeless> could just pass stdout and stderr to the child as is;)
[05:26] <mpt> The incremental output rocks, btw
[05:26] <stub> Want to collate stdout and stderr
[05:27] <lifeless> on pqm ?
[05:29] <spiv> lifeless: Also, test_on_merge wants to watch stdout/err for timeout reasons.
[05:29] <lifeless> should really be in pqm core ;0
[05:29] <spiv> Yeah, probably.
[05:30] <spiv> lifeless: what do you make of bug 37823?
[05:31] <lifeless> I think it renders whack
[05:31] <lifeless> https://launchpad.net/products/bzr/+bug/37823
[05:31] <mpt> Ubugtu, wakey wakey
[05:31] <spiv> mpt: It msged me to say "This bug is private".
[05:52] <dilys> Merge to devel/launchpad/: [trivial]  Don't insert random spaces in test_on_merge.py output (r3383: Stuart Bishop)
[06:21] <lifeless> spiv: interesting glitch in the rules
[06:21] <lifeless> spiv: we should fix that
[06:24] <spiv> lifeless: I can't see how it would happen, if you're referring to 37823.
[06:26] <lifeless> I am
[06:32] <lifeless> ok, I'm gonna take a break, its been 8 hours straight
[06:33] <lifeless> back in a bit
[06:33] <lifeless> BjornT: look at the rendering here - is it meant to look like that ?
[06:33] <lifeless> https://launchpad.net/products/bzr/+bug/37823
[06:33] <lifeless> spiv: ddaa has fixed is branch apparently
[06:36] <spiv> lifeless: hmm, yeah, pending-reviews agrees.  Cool, I'll do that review finally :)
[06:38] <dilys> Merge to devel/launchpad/: [trivial]  Fixes bug 2250 (Rosetta shows 'appoint additional translators' even when you don't have permission to use it) and bug 6666 (visited links on bug page have insufficient contrast) . (r3384: Matthew Paul Thomas)
[06:48] <stub> mpt: Should we be dropping BugTask.priority at the same time as your other work, or leave it for the future?
[06:48] <stub> (or someone else to deal with)
[07:05] <mpt> stub, sabdfl said to leave it
[07:05] <mpt> in case we use it later
[07:06] <stub> ok
[07:06] <mpt> though dropping it would have been easier, because then I'd know *all* uses of it in the code should be removed, not just some of them :-)
[07:07] <stub> mpt: You can rename the column ;)
[07:08] <stub> If you want to confirm that all uses are removed, 'ALTER TABLE BugTask RENAME priority TO obsolete_priority' should do the trick
[08:00] <zorglub> hi
[08:01] <zorglub> are rosetta imports processed ?
[08:15] <spiv> zorglub: There's an problem with them at the moment it seems, when carlos is awake it should be resolved.
[08:17] <jamesh> spiv: w.r.t. my TacTestHandler fixes, I had a few questions
[08:17] <jamesh> TacTestSetup, even
[08:17] <spiv> jamesh: Oh?
[08:18] <jamesh> spiv: (1) some uses create separate instances of the class for setup and teardown and some keep the instance around for teardown.  Is it worth supporting both uses?
[08:19] <jamesh> and (2) before my changes, the existing implementation handles teardown of daemons if the pidfile is still there from last run.  I wonder if it would be better to add an atexit handler to remove daemons?
[08:20] <jamesh> s/remove/kill/
[08:20] <spiv> jamesh: (1) No, just support one.  I'd prefer that the instance should be kept around, because it potentially makes things simpler for the implementation, but maybe that's a YAGNI.  But there should be only one way, either way (I know both are in use atm).
[08:21] <spiv> atexit isn't sufficient -- what if the test suite died ungracefully?
[08:21] <spiv> Or even more likely, a previous tearDown didn't get to the tac teardown, because something else failed first.
[08:22] <spiv> (Or a setUp failed after starting a tac, but before completing, therefore tearDown never runs)
[08:22] <jamesh> spiv: I think the support for not keeping the instance around probably hides some cases of tests not correctly cleaning up too
[08:22] <zorglub> spiv: ok thanks
[08:22] <spiv> zorglub: Feel free to nag carlos and/or file a bug if it's not fixed soon, though :)'
[08:22] <jamesh> potentially introducing order dependence in tests
[08:23] <jamesh> so perhaps setUp() should check for the pidfile and kill the old daemon + emit a warning if it finds the daemon
[08:24] <spiv> jamesh: Sounds good.
[08:24] <spiv> jamesh: I wonder if pidfiles are even necessary if we aren't fully daemonising...
[08:25] <jamesh> spiv: well, it helps us detect a previously running daemon
[08:25] <jamesh> spiv: which is a good thing from a robustness perspective
[08:26] <spiv> I guess I'm wondering if the way we're spawning these processes now means by default they'll die when the parent does... if that's not the case, we still want the pidfiles.
[08:26] <jamesh> they don't seem to ...
[08:26] <spiv> Fair enough.
[08:27] <jamesh> I suppose we could do that if there was a pipe between the two processes -- write end in the parent, read end in the child
[08:27] <jamesh> have the child exit on HUP
[08:28] <jamesh> not sure how best to do that in the twisted framework though
[08:28] <spiv> jamesh: Well, Twisted doesn't touch the SIGHUP handler.
[08:29] <jamesh> spiv: I don't mean UNIX signals -- I mean the HUP condition from poll()
[08:29] <carlos> morning
[08:29] <jamesh> or exception from select()
[08:29] <spiv> Oh, I see
[08:30] <jamesh> it might be easier to just continue with the pidfile code ...
[08:31] <spiv> jamesh: something like twisted.internet.stdio to hook up an object to an already open pipe, and then the attached protocol would see the connectionLost event.
[08:31] <spiv> But yeah, it's a bit messy, I'd stick with the pidfile stuff atm.
[08:32] <jamesh> if we got the pipe trick working, it should be very reliable -- the write end of the pipe gets closed by the OS when the test suite exits causing the hangup
[08:34] <spiv> jamesh: Assign a bug to me, I'll look at it sometime soon.  It's a nice solution.
[08:44] <jamesh> spiv: https://launchpad.net/products/launchpad/+bug/37837
[08:44] <Ubugtu> Malone bug 37837 in launchpad "Make daemons spawned by test suite exit more reliably" [Normal,Confirmed]
[08:45] <spiv> jamesh: Thanks.
[08:51] <lifeless> thank you god
[09:13] <spiv> carlos: around?
[09:13] <carlos> spiv: yes
[09:13] <carlos> hi
[09:14] <spiv> carlos: see my mail about rosetta-poimport.py?
[09:14] <carlos> spiv: yes, I already answered it
[09:14] <carlos> hmm
[09:14] <carlos> but my laptop didn't send the answer...
[09:14] <carlos> grrr
[09:14] <spiv> carlos: cool, zorglub was asking about imports earlier, you might want to let him know when it's fixed :)
[09:14] <carlos> spiv: it was fixed on Friday
[09:15] <spiv> carlos: Really?  That's odd.
[09:15] <carlos> spiv: but it was not cherrypicked...
[09:15] <spiv> Ah.
[09:15] <carlos> I didn't think it was necessary... until now...
[09:15] <spiv> I should say, "fixed and released" :)
[09:16] <spiv> carlos: This and runmirror have been spamming the error reports list all weekend, we've fixed the runmirror issue, it'd be nice to fix this one too.
[09:16] <spiv> It's sending an error mail every 10 minutes.
[09:17] <carlos> spiv: I know
[09:17] <carlos> spiv: with my email answer I asked stuart to cherry pick the patch
[09:17] <spiv> carlos: Ok.  Just nagging you before kiko does ;)
[09:17] <carlos> it's a one line change
[09:17] <carlos> spiv: kiko pointed me to that bug... :-P
[09:18] <spiv> :)
[09:18] <carlos> stub: hi
[09:18] <stub> carlos: hi
[09:18] <carlos> stub: could you cherry pick r3373 ?
[09:19] <carlos> stub: or apply the change manually? it's just a matter of rename a variable name
[09:19] <carlos> spiv: thanks for bugging me ;-)
[09:20] <stub> ok
[09:20] <spiv> carlos: Anytime :)
[09:20] <carlos> stub: thanks
[09:21] <lifeless> interesting statistic I'd like to know stub
[09:21] <lifeless> stub: meantime from cherrypick request to rollout
[09:22] <lifeless> stub: I think there is a incorrect perception that it takes days to get cherrypicks out there.
[09:22] <stub> We don't do enough to give a meaningful statistic - sample size is way too small
[09:22] <spiv> lifeless: "meantime"... that's how long stub is in a grumpy mood after doing a cherrypick? ;)
[09:23] <lifeless> stub: https://wiki.launchpad.canonical.com/FasterCodeUpdates
[09:23] <lifeless> stub: I have the feeling that everything in that spec can be addressed by 'request cherrypicks for template only changes'
[09:24] <lifeless> stub: but I have some concerns about trying to automate commits to production by anyone, particularly as *you still need to do a rollout* to get the changes in
[09:25] <stub> Yup. If cherry picks take time to rollout, it is generally because they are being batched.
[09:27] <stub> Having changes land too fast into production is often counter productive too - there have been a number of cases of simple fixes that have had to be rolled out not working, causing frustration and further quick fixes. Rather than investing time investigating and fixing the problem properly.
[09:27] <lifeless> stub: please jump into the discussion on that spec
[09:28] <stub> There is no discussion on that spec
[09:28] <lifeless> refresh it
[09:28] <stub> Nope
[09:29] <mpt_> lifeless, "I" needs a @NAME@
[09:29] <stub> oic
[09:29] <lifeless> mpt_: ?
[09:30] <mpt_> i.e. it's non-trivial to work out who wrote who "I" refers to
[09:30] <mpt_> s/who wrote//
[09:31] <lifeless> mpt_: context my small compatriot, context!
[09:32] <lifeless> or in other terms, WTF are you talking about ?
[09:32] <jamesh> spiv: does the rewrite rule I gave in https://launchpad.net/products/launchpad/+bug/37818 sound like it would fix the problem?
[09:32] <Ubugtu> Malone bug 37818 in launchpad "http://bazaar.launchpad.net/~user/product/branch is a 404" [Minor,Confirmed]
[09:34] <mpt_> lifeless: context! You were talking about "the discussion on that spec". The discussion you have added is not obviously by you. But the amount of time I have now spent trying to explain this has now exceeded the amount of time required for me to add your wikiname to the page myself, so I'll stop talking
[09:34] <lifeless> mpt_: oh, the spec. Sure, know I know what you are talking about.
[09:34] <spiv> jamesh: It sounds likely to me.
[09:35] <jamesh> spiv: I suppose it needs admin intervention to fix though?
[09:35] <spiv> jamesh: I guess file an rt request... yeah.
[09:35] <lifeless> erm
[09:35] <lifeless> spiv, jamesh - whats this for ?
[09:35] <lifeless> if its vostok? we had some serious trouble with those rules.
[09:35] <jamesh> lifeless: go to e.g. http://bazaar.launchpad.net/~radix/subol/main.dev and get a 404
[09:35] <spiv> AFAIK, the admins are the only people with access to that apache conf.
[09:36] <lifeless> I'd like to verify it offline before *any* attempt to change it in production
[09:36] <jamesh> lifeless: a rewrite rule to redirect to the same thing with a slash on the end
[09:36] <spiv> jamesh: lifeless is right about the trouble we had with them, though :)
[09:36] <lifeless> jamesh: theres a much easier fix
[09:36] <jamesh> oh?
[09:36] <SteveA> stub: i've wondered if it is possible to have launchpad running on some domain use new presentation code, but run against the production database, as a useful kind of staging.
[09:36] <lifeless> we have a rule that just needs a / turned into (/|$)
[09:37] <lifeless> that should fix it in one hit without generating double lookups
[09:37] <jamesh> lifeless: you need a redirect in either case
[09:38] <jamesh> or at least want a redirect
[09:38] <lifeless> jamesh: why ?
[09:38] <stub> SteveA: What does that give us that staging doesn't? Except for the ability for untested UI changes to create broken data in the production database?
[09:38] <jamesh> lifeless: programs trying to resolve relative URIs
[09:39] <lifeless> jamesh: please go on
[09:39] <lifeless> oh, I see where you are coming from
[09:40] <lifeless> yes, we could do that too. we have a separate problem.
[09:40] <lifeless> https://launchpad.net/products/bzr/+bug/37823
[09:40] <lifeless> garh
[09:40] <lifeless> ubugtu SFTU I know its private
[09:41] <SteveA> stub: what does that give us that staging doesn't?  users.
[09:42] <spiv> Of course, fixing the 404 alone doesn't solve the whole issue -- it'll probably lead to "the URL for my branch is empty", because our apache config doesn't show the .bzr directory in listings.
[09:42] <stub> SteveA: Why would users be using bleedingedge.launchpad.net? If users *are* using it, why would be also want to bother with the 'standard' site?
[09:42] <SteveA> because we expect things to break more often on the bleeding edge
[09:42] <jamesh> spiv: that'd involve updating IndexIgnore to not exclude dot files
[09:43] <stub> I don't see how that improves the end user experience
[09:43] <lifeless> they can choose when to bleed
[09:44] <stub> I see the preferred launchpad ui giving more exceptions, and the production environment ending up more complex creating larger maintenance burdens with the necessary larger downtime periods.
[09:44] <lifeless> jamesh, spiv please test a tweaked config offline, then I'm extremely happy for an rt request to be filed
[09:45] <lifeless> I think its worth solving both bugs at once
[09:45] <jamesh> lifeless: I'm not sure what bug 37823 says because it is private, btw :)
[09:45] <lifeless> jamesh: you should be able to access it
[09:45] <lifeless> btw stub and I can do apache config on vostok
[09:45] <jamesh> lifeless: why?
[09:45] <spiv> lifeless: launchpad-dev doesn't seem to be subscribed.
[09:45] <lifeless> so you dont need an rt request
[09:46] <spiv> jamesh: try now
[09:46] <lifeless> subscribed
[09:47] <spiv> lifeless: heh, look at the activity log, we both subscribed launchpad developers :)
[09:47] <lifeless> ;)
[09:47] <spiv> I'm mildly impressed that malone didn't blow up ;)
[09:48] <jamesh> it doesn't do any of the "midflight collision" stuff that bugzilla does
[09:50] <lifeless> well that was obviously a three-way merge with the same result on both sides
[09:50] <spiv> lifeless: ...obviously.  ;)
[09:51] <SteveA> stub: so, upon reflection, you feel that this is not a good idea.
[09:54] <carlos> stub: hi, we got some 'garbage' from openoffice (it was not a problem with Rosetta) and we need to cleanup Rosetta from those broken imports
[09:54] <carlos> stub: I prepared this https://chinstrap.ubuntu.com/~dsilvers/paste/filedmfMPY.html to do the cleanup and then import the fixed .po files again
[09:55] <carlos> stub: I'm going to test it on staging when the mirror ends
[09:55] <stub> SteveA: No. Landings that meet the criteria that the new environment would allow (template changes only and no dependancies on python or db schema changes that have not yet been rolled out) are very rare, and thus the new environment would rarely be any different from the real production environment. It would only serve to complicate things.
[09:55] <carlos> after testing it on staging, could you execute it on production?
[09:56] <SteveA> stub: i think you meant "yes" as in "yes, on reflection i feel that this is not a good idea"
[09:57] <SteveA> although, i should clarify that i'm talking about changes in presentation code, python and template, not just templates, for bleedingedge.whatever
[09:57] <stub> SteveA: i guess
[09:58] <stub> I need a nap ;)
[09:58] <SteveA> which increases the scope of what could be rolled out there early
[09:59] <stub> If you increase the scope, then we start having an issue with broken code irreparably corrupting the production database.
[09:59] <stub> Or reparably - it is still a pita when it happens with fully reviewed and tested code.
[10:00] <SteveA> have you seen any times when presentation code has done this?
[10:00] <lifeless> SteveA: so when you say presentation you are excluding anything that changes canonical.launchpad.database
[10:00] <lifeless> ?
[10:00] <SteveA> not quite that
[10:01] <stub> I've seen plenty of code that should be database fall through into the presentation layer. And if this is a mechanism for bypassing beurocracy, then more code will fall through like that.
[10:01] <SteveA> i'm saying anything in launchpad/templates or launchpad/browser
[10:01] <SteveA> the rationale for this is to get some kind of staging system actually used somewhat
[10:10] <jamesh> lifeless: tested the rewrite URL I proposed at https://launchpad.net/products/bzr/+bug/37823 locally
[10:11] <jamesh> seems to work correctly (does redirects where it should, gives 404s where it should)
[10:11] <lifeless> ok.
[10:11] <lifeless> thanks
[10:24] <stub> lifeless: Cherry picking https://lists.ubuntu.com/mailman/private/arch-commits/2006-March/005638.html , I get  WARNING: Conflict adding file lib/canonical/launchpad/webapp/z3batching/__init__.py.  Moved existing file to lib/canonical/launchpad/webapp/z3batching/__init__.py.moved.
[10:24] <stub> lifeless: Yet that patch doesn't touch that file
[10:25] <lifeless> stub: did that file already exist locally ?
[10:25] <lifeless> or something ?
[10:27] <stub> lifeless: https://chinstrap.ubuntu.com/~dsilvers/paste/file4RdtLb.html
[10:30] <stub> I get the same thing trying to cherry pick r3382, so I guess it would be any patch after the one that moved that file
[10:33] <mpt> yow, +tickets isn't batched
[10:34] <mpt> BjornT, ping
[10:56] <lifeless> stub - do a revert
[10:56] <lifeless> stub: then do bzr st
[10:56] <lifeless> is there any output from bzr st ?
[11:03] <lifeless> mpt: your branch 35086 has conflicts
[11:17] <BjornT> mpt: pong (i'm having problems with my internet connection)
[11:21] <Mithrandir> hmm, can anybody tell me why htts://launchpad.net/people/tfheen shows the ubuntu-drivers logo in the list of logos?
[11:22] <jamesh> Mithrandir: because you are a member of that team?
[11:23] <Mithrandir> oh, indirectly I am, it seems.
[11:24] <ajmitch> for some reason core-dev was added as a member
[11:25] <Mithrandir> see #u-d for the description
[11:25] <Mithrandir> or reason, or whatever. :-)
[11:30] <mpt> BjornT, you wrote: "+   * On +filebug ... Also provide a link to file a bug on any related packages." There's a bug report saying that should be on the product's +bugs page, rather than its +filebug page. Thoughts?
[11:31] <mpt> For example, /products/a/+bugs should link to /distros/b/+source/a/+bugs
[11:46] <carlos> stub: is staging being updated?
[11:46] <carlos> it's taking too much time, isn't it?
[11:49] <jordi> carlos: there's a zwiki and plone pots that I'm leaving on hold
[11:49] <jordi> the rest is imported
[11:49] <carlos> jordi: cool, thanks
[11:49] <jordi> carlos: how hard would it be to further filter between distro and series stuff?
[11:50] <jordi> ie, "show needs_review for any kind of file belonging to product series"
[11:50] <carlos> jordi: not too much... I already thought that and I guess I will add it after KDE support lands
[11:50] <jordi> so I can find series po files easily
[11:50] <jordi> ok, thanks
[12:07] <stub> carlos: The staging server did not update properly. I'm sorting it now.
[12:08] <carlos> stub: ok
[12:08] <carlos> anyway, I'm going to move my scripts to use at noon
[12:08] <carlos> stub: thanks
[12:09] <stub> carlos: Updates are probably starting an hour later now too with London kicking over to summer time
[12:09] <carlos> stub: well... my cronscript is also at London time zone
[12:15] <jamesh> is there any way to tell cron that a particular crontab should be interpreted as UTC?
[12:22] <stub> carlos: back up
[12:24] <carlos> stub: cool, thanks
[12:38] <dilys> Merge to devel/launchpad/: [trivial]  Remove comments for removed table (r3385: Stuart Bishop)
[12:47] <erdalronahi> carlos: Hi, just answered your mail on the mailinglist
[12:47] <erdalronahi> thanks for helping
[12:50] <carlos> erdalronahi: I already answered too ;-)
[12:50] <carlos> erdalronahi: you are welcome
[12:50] <erdalronahi> ;-)
[12:50] <erdalronahi> the re-import will be finished tomorrow?
[12:51] <carlos> not sure
[12:52] <carlos> I'm still finishing testing the deletion
[12:52] <carlos> and we need to reimport breezy and dapper...
[12:52] <carlos> count with Wednesday
[12:53] <carlos> dapper's openoffice is really huge
[12:53] <carlos> now that we include the documentation...
[12:54] <jordi> reimport breezy and dapper?
[12:54] <jordi> WTF?
[12:56] <carlos> jordi: OpenOffice
[12:56] <mdke> so is rosetta ready for dapper now for packages other than openoffice?
[12:56] <carlos> mdke: and KDE
[12:57] <carlos> but due the massive imports that we are going to do this week... I'm not going to announce it yet
[12:57] <mdke> oh cool. all the upstream translations are in for everything except kde and ooo?
[12:57] <carlos> mdke: most of them, yes
[12:57] <carlos> I'm still reviewing what's missing
[12:58] <carlos> but mainly KDE
[12:58] <carlos> is missing
[12:58] <mdke> very cool
[12:58] <carlos> and OO is broken...
[12:59] <erdalronahi> but the translations from Breezy are not yet imported, right?
[12:59] <carlos> stub: I guess is ok if I use my staging rights to check some deletions before I ask you to do it on production, right?
[12:59] <erdalronahi> The bulk of our translations is there, not upstream
[12:59] <carlos> erdalronahi: yeah, not yet imported
[01:00] <carlos> that's another point to deferer the announcement
[01:00] <stub> carlos: Sure. Staging is there to be abused ;)
[01:00] <carlos> ok
[01:00] <carlos> ;-)
[01:07] <carlos> stub: btw... how's going the cherrypick?
[01:07] <stub> carlos: I'm getting spurious conflicts
[01:08] <carlos> with mine?
[01:08] <carlos> it's one line change + a big test change
[01:16] <stub> carlos: So. Conflicts in files that your patch (and others I need to cherry pick) don't touch.
[01:16] <stub> c/So/No/
[01:16] <carlos> oh
[01:16] <carlos> ok
[01:23] <jamesh> lifeless: I put together this simple script to convert a tree of bzr branches into a repository: http://people.ubuntu.com/~jamesh/make-bzr-repo.sh <- does it look sane?
[01:30] <lifeless> jamesh: other than being in sh ?
[01:33] <mpt> jordi, ping
[01:35] <stub> lifeless: I've done the cherry picks using diff & patch. Running tests now.
[01:37] <jordi> mpt: hi
[01:40] <mpt> jordi, do you have a more definite idea yet of whether you'll be able to attend Extramadura in September?
[01:44] <koke> carlos: around? our l10n-es memberships have expired :)
[01:44] <carlos> koke: hi
[01:44] <carlos> koke: really? :-P
[01:44] <koke> Jorge Bernal   	2005-04-01  	 Expired on 2006-04-02
[01:45] <carlos> X-)
[01:46] <carlos> koke: fixed
[01:46] <carlos> wow, the list of pending people is huge...
[01:47] <carlos> koke: why aren't you rejecting people? there are many people waiting since 2005
[01:47] <carlos> well, rejecting or accepting them...
[01:49] <koke> I usually wait to see if they subscribe to the list
[01:49] <SteveA> mpt: http://blog.drinsama.de/erich/en/linux/2006040302-msie-on-linux
[01:50] <SteveA> "You can run MSIE 6 on Linux quite well by now. Not that there is any reason to do so. (Okay, maybe if you are a webdesign professional you'll want to make sure your layout works fine with MIES, too.)
[01:50] <SteveA> "
[01:50] <mpt> awesome
[01:51] <SteveA> it is two days too late for an april fool
[01:51] <SteveA> i wonder if ubuntu will put MSIE in multiverse ;-)
[01:52] <mpt> There's a wiki page you can propose it for inclusion, iirc
[01:53] <siretart> SteveA: installing that isn't that hard either. we already ship wine
[01:54] <ajmitch> SteveA: there are scripts around that setup ie 5, 5.5 & 6 in a few minutes
[01:54] <ajmitch> it even works :)
[01:55] <SteveA> awesome
[01:55] <ajmitch> useful for checking layout
[01:56] <erdalronahi> carlos: sorry, I didn't get your answer due to a connection error
[01:57] <erdalronahi> When can we hope to see the translations from Breezy imported into Dapper?
 The bulk of our translations is there, not upstream
 erdalronahi: yeah, not yet imported
 that's another point to deferer the announcement
[01:57] <carlos> erdalronahi: as soon as I finish fixing KDE and OpenOffice, I will work on it
[01:58] <erdalronahi> That means?
[01:59] <carlos> erdalronahi: that I will try to get it ready to be executed next week
[01:59] <erdalronahi> ok, thanks
[01:59] <carlos> stub: Is there any way to use JOINS with an UPDATE sentence?
[01:59] <stub> carlos: Yes.
[01:59] <stub> Check the 8.1 docs - I think it was a recent introduction
[02:00] <carlos> ok
[02:00] <carlos> thanks
[02:00] <carlos> without joins... the update is taking ages
[02:00] <LeeJunFan> carlos: fixing kde and openoffice media:/? you're my hero :)
[02:00] <stub> file:///usr/share/doc/postgresql-doc-8.1/html/sql-update.html
[02:01] <carlos> LeeJunFan: media:/ ?
[02:01] <carlos> stub: thanks
[02:06] <LeeJunFan> carlos: openoffice doesn't like kde's media:/ url's when you save/load.
[02:06] <carlos> LeeJunFan: sorry dude... I'm talking about translations with Rosetta...
[02:07] <carlos> I don't know KDE programming and thus... I cannot fix that
[02:09] <stub> carlos: Cherry picks done
[02:09] <carlos> stub: cool, thanks
[02:12] <carlos> erdalronahi: I'm not sure I will have OO fixed today, the tests I'm executing atm are taking much more time than I expected
[02:13] <carlos> and will not be ready to be executed today by our DBA
[02:14] <carlos> so it will be dalayed until tomorrow  (I will finish the tests today and request its execution today)
[02:20] <erdalronahi> carlos: ok, I will have a look now and then :)
[02:20] <carlos> erdalronahi: I will announce it anyway
[02:20] <carlos> when it's ready
[03:03] <kiko> hey salgado!
[03:03] <salgado> yo kiko
[03:03] <kiko> how's it going old man?
[03:04] <salgado> not too bad. rsyncing stuff back from the laptop
[03:04] <kiko> we upgraded to 8.1 on anthem and on the workstations fwiw
[03:04] <kiko> seems to be working well
[03:04] <salgado> ah, good
[03:04] <kiko> anthem is breezy
[03:04] <kiko> any problems noticed so far?
[03:05] <salgado> no, nothing
[03:05] <kiko> great
[03:20] <kiko> ping ***
[03:20] <kiko> is anyone radically opposed to having the launchpad meeting this wednesday?
[03:20] <kiko> I'll need to be out this thursday morning and steve isn't going to be around
[03:23] <salgado> is it a known problem that the binarypackagename widget is prefilled with the wrong value when you try to edit the status of a bug? (https://launchpad.net/distros/ubuntu/+source/codespeak-lib/+bug/6128 shows the problem)
[03:23] <Ubugtu> Malone bug 6128 in codespeak-lib ""py.test2.4" fails" [Normal,Confirmed]
[03:25] <kiko> what value is it prefilled with?
[03:25] <kiko> bradb?
[03:25] <salgado> "Re: "py.test2.4" fails"
[03:26] <kiko> salgado, there is nothing in the box AFAICS
[03:28] <salgado> indeed, I reloaded the page and can't see it anymore
[03:28] <salgado> I'm sure I didn't paste it there, though. specially because I didn't copied that string from anywhere
[03:29] <bradb> salgado: Have you ever seen that problem before?
[03:29] <salgado> no. first time
[03:30] <bradb> ok
[03:34] <kiko> salgado?
[03:35] <salgado> yep?
[03:35] <kiko> oh, didn't see your comment above
[03:35] <kiko> why did you drop off?
[03:37] <kiko> spiv, ping?
[03:37] <salgado> kicked the power cord
[03:37] <kiko> doh
[03:37] <kiko> the whole room's power cord?
[03:37] <kiko> do the UPSs not hold water?
[03:37] <kiko> perhaps I should give you guys the new one I bought
[03:38] <kiko> PERHAPS
[03:38] <salgado> matsubara has the UPS, and no, it doesn't work
[03:39] <kiko> these UPSs are not worth shit, we shouldn't by anything but APC any longer
[03:39] <kiko> we should replace them gradually
[03:41] <salgado> that would be great
[03:42] <kiko> yeah, but will take a few months as they are expensive.
[03:50] <matsubara> who have permission to edit support request for the launchpad product?
[03:52] <kiko> mmmm
[03:53] <matsubara> nm kiko, bug 3157
[03:53] <Ubugtu> Malone bug 3157 in launchpad "Anyone should be able to edit a support ticket" [Normal,Confirmed]  http://launchpad.net/bugs/3157
[04:21] <koke> carlos: I'm a member again but not an admin
[04:21] <carlos> kiko: fixed
[04:22] <carlos> stub: I cannot resume a screen session I have on asuka
[04:22] <matsubara> kiko: bug 6429 would benefit of some attention. Lots of support requests on it.
[04:22] <Ubugtu> Malone bug 6429 in grub-splashimages "Links to consumed tokens generate 404 errors" [Unknown,Unknown]  http://launchpad.net/bugs/6429
[04:22] <carlos> stub: is that normal?
[04:22] <carlos> stub: of course, I created it ;-)
[04:22] <kiko> matsubara, that's a salgado bug, you know -- perhaps you should talk to him?
[04:23] <stub> carlos: you are not connected as the user who created the session, or if you ran it as launchpad, you have sudo'd to the launchpad user rather than connect directly via ssh.
[04:23] <carlos> ok, fixed... My fault
[04:23] <kiko> stub, can you remind me what revision we are currently running?
[04:23] <carlos> stub: the problem is that it was already attached
[04:23] <carlos> by a previous session that died
[04:23] <stub> screen -r -d
[04:23] <matsubara> kiko: I'll assign to him then.
[04:23] <carlos> stub: yeah, I did it already
[04:23] <carlos> thanks anyway
[04:23] <kiko> matsubara, wait
[04:23] <kiko> matsubara, grub-splashimages?
[04:24] <kiko> matsubara, and also.. there's a launchpad bug on this, isn't there?
[04:24] <matsubara> kiko: yes, I assigned the launchpad one to him.
[04:24] <kiko> ok
[04:24] <stub> We are now running r3354 with the following revisions cherry picked in: r3358, r3362, r3373, r3382
[04:24] <kiko> invalidate that one then?
[04:24] <kiko> thanks stub
[04:25] <matsubara> kiko: the task or whatever it's called now. I can't invalidate the grub-splashimage one. It's not editable
[04:26] <kiko> horrible
[04:29] <kiko> salgado, did you see your MM account is active?
[04:30] <salgado> kiko, MM = mawson?
[04:30] <kiko> mirror management and yes, mawson
[04:33] <salgado> yes, I've seen it's active
[04:33] <salgado> should I just make a new checkout from rocketfuel and run it against staging's db?
[04:34] <kiko> why not?
[04:34] <matsubara> carlos: ping
[04:35] <salgado> just wanted to make sure this is the right thing to do
[04:35] <carlos> stub: hmm, could you take a look at https://chinstrap.ubuntu.com/~dsilvers/paste/file9i98Sb.html and tell me if there is any obvious way to improve those queries? the first update is taking ages to be executed on staging (more than 30 minutes)... and we need to execute that on production tomorrow after i'm sure all things are "migrated" as I expected...
[04:35] <carlos> matsubara: pong
[04:36] <matsubara> carlos: is there any open bug on OOPS-78D530?
[04:36] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/78D530
[04:36] <SteveA> bradb: hey there
[04:36] <bradb> SteveA: hi
[04:37] <carlos> matsubara: that's already fixed
[04:37] <carlos> matsubara: I fixed it in London
[04:37] <carlos> matsubara: did it appear again?
[04:38] <stub> carlos: It might run faster if you replace the Foo JOIN Bar JOIN Baz syntax with FROM Foo, Bar, Baz, and move the ON clauses into the WHERE clause.
[04:38] <matsubara> carlos: could you point me to the bug number? I'm just triaging open support requests.
[04:39] <SteveA> bradb: up for some coffeehousing over skype?
[04:39] <matsubara> carlos: i'll link to the bug number and close the support request.
[04:39] <carlos> stub: is that faster???
[04:40] <carlos> stub: I had that way and as it's also slow, I changed it to use joins
[04:40] <bradb> SteveA: sure, heh
[04:40] <carlos> matsubara: I don't think I filed a bug as I introduced that bug the same week
[04:40] <carlos> matsubara: but let me check, just in case...
[04:40] <stub> carlos: actually, it will generate the identical plan so it won't help
[04:42] <bradb> SteveA: calling...
[04:42] <SteveA> i restarted skype
[04:43] <SteveA> try now
[04:43] <carlos> matsubara: no, I didn't file a bug as it was a side effect of fixing another bug
[04:43] <carlos> and I did the fix using the old branch
[04:44] <bradb> hm, not working. i'll try restarting skype here too, for good measure.
[04:44] <matsubara> carlos: ok, thanks
[04:44] <carlos> matsubara: you are welcome
[04:45] <stub> carlos: Can't really improve that. Selecting the results on jubany only takes about 20 seconds. But updating the 3.67 million rows will take a while.
[04:46] <carlos> there are 3.67 million rows???
[04:46] <carlos> wow
[04:47] <carlos> stub: If you explain me the way to do it, most of those updates could became a DELETE from two tables
[04:47] <carlos> i'm doing the update to remove the reference to that row
[04:47] <carlos> so I can execute the DELETE
[04:50] <carlos> stub: I'm not removing the POSelection rows because I will recreate them again with next import and it's ok to leave them with those fields set to NULL, but If is faster... I can just do a DELETE ON CASCADE of all matching POSelection rows
[04:50] <stub> You can't do a delete on cascade unless I recreate the foreign key constraints as ON DELETE CASCADE
[04:51] <kiko> aieee
[04:54] <carlos> stub: so your script to delete POTemplate deletes all dependencies first
[04:54] <stub> carlos: yes
[04:55] <stub> (but on delete cascade has to do that too - just does it automatically)
[04:56] <carlos> stub: well, but the delete on cascade doesn't need to do the UPDATE...
[04:56] <carlos> stub: what's faster? a DELETE or an UPDATE?
[04:56] <stub> I think we should redo these constraints, some on delete cacade, some on delete nullify, but I won't have that ready for tomorrow.
[04:56] <stub> carlos: I can't answer that without benchmarking it ;)
[04:58] <carlos> stub: ok, then... Do you think is doable that we have a command on execution that will block those tables (and Rosetta) for an hour or even more?
[04:59] <carlos> I guess is better if I split the SQL commands to do it in smaller steps, right?
[04:59] <stub> carlos: We can schedule launchpad downtime
[04:59] <stub> carlos: Or redo it as a Python script to do a few at a time.
[04:59] <carlos> stub: I can do a few at a time with SQL
[05:00] <carlos> I'm handling 13-14 POTemplates at the same time
[05:00] <carlos> I can do one, commit, another one, commit, etc...
[05:13] <stub> carlos: It might help, but there will still be significant lengths of time with the tables locked.
[05:13] <carlos> ok, I will go then with the python script
[05:14] <carlos> stub: I guess that the way to go is execute that query, get a slice of 1000-2000 entries, update them, commit, get a new slice of entries, commit ... until It's done
[05:15] <carlos> stub: do you think I should get more/less entries per transaction?
[05:15] <stub> carlos: yes. I'd go with a chunk size of 5000
[05:15] <carlos> ok
[05:16] <carlos> stub: Which user should I use to connect to the database? launchpad?
[05:16] <stub> If it has the relevant rights, sure.
[05:16] <stub> Otherwise, whatever. postgres if necessary.
[05:16] <carlos> stub: I need to delete rows so I guess that's the user that will have all rights as I don't have such action available for other scripts
[05:17] <carlos> ok
[05:18] <carlos> I will prepare it, ask for review and leave it as a tool to fix this kind of breakages... something tells me that we will need it again in the future...
[05:28] <carlos> stub: night
[05:31] <elmo> bzr: WARNING: Unable to update the working tree of: <blahblah>
[05:32] <elmo> wassat mean?
[05:32] <SteveA> dunno.  try #bzr
[05:33] <ddaa> elmo: that means bzr coders do not know the distinction between a warning and an informative message.
[05:34] <ddaa> elmo: when pushing via sftp, the working tree cannot be updated (for various reasons)
[05:34] <ddaa> if the branch you are pushing to (via sftp) has a working tree, bzr will print this warning.
[05:34] <ddaa> I _think_ that is always true for v6 branches (created with bzr-0.7)
[05:35] <elmo> ddaa: ah, I see, thanks
[05:35] <ddaa> actually, there was a lot of discussion about fixing that message, I think it might have improved in 0.8
[05:36] <iwj> How can I tell who the current bug contact(s) are for a package ?  I'm looking at  https://launchpad.net/distros/ubuntu/+source/psutils  and I don't see it.
[05:36] <ddaa> elmo: the result of such a push (with v6 branches) is working tree with "uncommitted changes"
[05:36] <ddaa> which is quite confusing.
[05:36] <elmo> ddaa: hmm, well that affect my ability to submit to pqm?
[05:36] <ddaa> elmo: absolutely not
[05:37] <kiko-phone> iwj, if you click on Bugmail settings they are included in a portlet in the lower left.
[05:37] <kiko-phone> would you like me to include that portlet in the main page?
[05:38] <iwj> Oh, so they are.  I clicked on `bugmail settings' but I didn't realise that the existing state I would be modifying would be hidden in the corner.
[05:38] <iwj> Including that info in the `"psutils" source package in ubuntu:' info would be sensible.
[05:39] <kiko-phone> I'll do that now, thanks.
[05:39] <iwj> Really, the whole contents of that portlet should be in the main body of the distros/ubuntu/+source/psutils page ...
[05:41] <kiko-phone> yep
[05:49] <iwj> Thanks.
[06:03] <kiko-phone> iwj, in PQM now.
[06:09] <kiko-phone> is PQM hung?
[06:11] <elmo> nothing's running
[06:12] <kiko-phone> odd.
[06:29] <elmo> OH MY GOD bzr push is so slow
[06:29] <kiko-fud> elmo, rsync or sftp?
[06:29] <elmo> err...
[06:30] <elmo> look, over there, something really shiny and interesting!
[06:30] <kiko-fud> rsync is usually much faster
[06:31] <ddaa> yup
[06:31] <ddaa> sftp push will alledgedly get much better with knits
[06:31] <elmo> ok, so I'm an idiot.  but how do I use rsync?
[06:31] <elmo><EMAIL_ADDRESS>doesn't seem to work
[06:31] <ddaa> elmo: man! this is going to the quotes page!
[06:32] <kiko-fud> elmo, first, you need bzrutils installed, and second, you just use "chinstrap.ubuntu.com:/..."
[06:32] <elmo> you mean bzrtools, I guess, but ok, trying
[06:33] <kiko-fud> sorry, yes, doing 4 things at once
[06:33] <kiko-fud> but now going to have lunch
[06:33] <ddaa> the best strategy ATM for launchpad-sized branches is to have shared repo and rsync it wholesale (by hand) to chinstrap.
[06:34] <elmo> ddaa: isn't that pretty much what bzr push with rsync does?
[06:34] <ddaa> elmo: bzr branches should not be uploaded to the Baz archive anyway.
[06:35] <ddaa> rather something like "rsync -a --delete mybranch chinstrap:/home/warthogs/archives/elmo/launchpad"
[06:35] <ddaa> or "rsync -a --delete mybranch/ chinstrap:/home/warthogs/archives/elmo/launchpad/cleanup" if the names differ
[06:35] <elmo> hmm, ok, I'll do that instea
[06:35] <elmo> thanks
[06:36] <ddaa> elmo: that's pretty much what bzr push with rsync does, but I just have too much trouble to make that one to work properly
[06:37] <ddaa> also, bzr push does (AFAIK) know about shared repos, and using that with rsync saves you 300MB of upload for every new branch.
[06:37] <ddaa> ... does _not_ know...
[06:38] <ddaa> then you can have single script to upload the whole repo whenever you want.
[07:35] <carlos> kiko-fud: I just added to pending review KDE support, at the end, it was not so difficult and includes a test ;-)
[07:36] <carlos> see you!
[08:00] <jblack> Ok guys. I'm out. I'll be leaving the mailing lists presently, so it'll be best to get ahold of me via phone, #bzr or email.
[08:01] <jblack> You're a great team and you do good things. Keep honest and do good work.
[08:01] <salgado> jblack, good luck, dude. we'll miss you here
[08:02] <bradb> best of luck jblack
[08:02] <jblack> salgado: I'm sure our paths will cross again. We don't live in _that_ big of a world.
[08:03] <ddaa> dunno the cause, but dapper feels snappier than brezzy
[08:03] <ddaa> maybe it's the kernel, or maybe it's the working video accell...
[08:03] <jblack> Anyways, take care guys and do well. Viva la bzr! =D
[08:04] <bradb> i'm happy that my built-in wireless works, even n-m seems not to notice
[08:04] <ddaa> bradb: took a bit of poking around, since AGPFastWrites now cause xorg to lock, but now I actually have 3D accell. Need to waste some money and time on things like tuxrace, Q3 and SOL, now :)
[08:04] <bradb> s/even/even though/
[08:05] <bradb> heh
[08:16] <bradb> mpt: I sent you a patch to fix your Malone Simplifications test failures.
[08:50] <kiko> lifeless, elmo: pqm seems to be disabled.
[08:52] <salgado> and staging is still dead
[08:53] <kiko> wtf is wrong with these people
[09:15] <ddaa> kiko: salgado: the branch puller (runmirror on supermirror@vostok) appears to be broken
[09:15] <kiko> oh?
[09:15] <ddaa> kiko: don't you read your error reports?
[09:15] <kiko> ddaa, your script also seems to be broken, needing a database update/rollout
[09:15] <kiko> update-branches
[09:15] <kiko> I do
[09:15] <ddaa> kiko: just done rollout
[09:15] <kiko> cool
[09:16] <kiko> well
[09:16] <kiko> the runmirror script stopped sending me output at 2:40 this morning
[09:16] <kiko> does that mean it was fixed?
[09:16] <kiko> or did it just die?
[09:16] <ddaa> uh... right :)
[09:16] <ddaa> it's no longer whining...
[09:24] <ddaa> salgado: can you fix the branch puller?
[09:25] <ddaa> it's really dead
[09:25] <kiko> not running at all?
[09:26] <ddaa> the bzr.dev branch published by launchpad is out of date
[09:26] <ddaa> well, that or it's running slogging its way slowly through some backlog...
[09:27] <salgado> I guess I can
[09:27] <ddaa> mh
[09:27] <salgado> ddaa, is https://lists.ubuntu.com/mailman/private/launchpad-error-reports/Week-of-Mon-20060403/024961.html the problem you're refering to?
[09:27] <ddaa> it looks like it's running actually (looking at vostok top)
[09:28] <ddaa> though, with no measurable CPU activity...
[09:28] <kiko> strace it!
[09:29] <ddaa> man, I understand why people prevented women from working... mine is blathering on the phone next door
[09:31] <salgado> ddaa, I think it was the http://gangotri.ubuntu.com:9000/supermirror-pull-list.txt page that was broken
[09:32] <ddaa> kiko: I do not have enough privs to strace
[09:32] <kiko> blimey
[09:32] <kiko> who is the script running as?
[09:32] <ddaa> user is supermirror
[09:33] <kiko> and you can't su to him?
[09:33] <ddaa> no
[09:33] <ddaa> currently, have to ask elmo/Znarl, and frankly they have better things to do
[09:34] <ddaa> there was discussion in London about transferring that stuff to the DBAs
[09:35] <kiko> DBAs?
[09:35] <kiko> nooooo
[09:36] <ddaa> salgado: yes, that's the problem I'm referring to
[09:37] <salgado> is it possible that the breakage was on that page?
[09:37] <salgado> the script will not produce any output if it runs successfully
[09:37] <salgado> which is intentional, since it runs every 5 minutes
[09:38] <kiko> that script was broken, we know it, right?
[09:39] <salgado> no
[09:39] <salgado> that error message was because the content it got from http://gangotri.ubuntu.com:9000/supermirror-pull-list.txt was not what it expects it to be
[09:40] <salgado> although it might be desirable to fail graciously if the content of that page is not what it expects, the problem wasn't actually in the script, AFAICT
[09:40] <kiko> mmmm
[09:41] <kiko> did you see the error message that was happening until today 2:40am?
[09:41] <salgado> ah, there's another one?
[09:42] <kiko> well
[09:42] <kiko>   File "/srv/sm-ng/lib/jobmanager.py", line 59, in branchStreamToBranchList
[09:42] <kiko>     (branchnum, branchsrc) = line.split(" ")
[09:42] <kiko> ValueError: need more than 1 value to unpack
[09:42] <salgado> the only one I've seen is the "ValueError: need more than 1 value to unpack"
[09:42] <salgado> yes, this one happened lots of times
[09:42] <salgado> that page is working fine now
[09:42] <salgado> ddaa, ^^
[09:42] <kiko> we could at least fix that codepath though
[09:45] <ddaa> salgado: I take it you somehow fixed the error reporting, so it would give a listing of failure in a reasonable format
[09:45] <salgado> kiko, you mean, to skip the branches for which we can't get an id and src url?
[09:45] <ddaa> if that's the case, it would make much sense just to log a warning if some line fails to parse (including the faulty line).
[09:45] <kiko> yeah.
[09:46] <ddaa> anyway, launchpad should not ever generate such a line...
[09:46] <salgado> exactly
[09:47] <ddaa> but it makes sense to log an error (better than warning) and proceed rather than blowing up.
[09:47] <salgado> I'm pretty sure this will only happen if that page is completely busted
[09:47] <salgado> in which case, we'll end up skipping all lines
[09:48] <kiko> bustificated
[09:48] <kiko> bustified
[09:48] <kiko> abustated
[09:48] <kiko> you know how it feels
[09:48] <kiko> the lowercase failure
[09:50] <ddaa> I'm pretty pretty sure the runmirror script is hung.
[09:50] <ddaa> Need to figure out how and when will the new code be rolled out.
[09:51] <ddaa> debiggin
[09:51] <ddaa> debugging this thing is like trying to hit a grue with a pea shooter
[10:20] <mpt> BjornT, ping
[10:21] <kiko> hey mpt
[10:21] <mpt> hi kiko
[10:22] <kiko> how's it going down under?
[10:23] <BjornT> hi mpt
[10:23] <mpt> kiko, I'll answer that question when I'm fully awake
[10:23] <mpt> :-)
[10:24] <ajmitch> mpt: just don't look out the window then
[10:24] <mpt> BjornT, https://launchpad.net/distros/debian/+source/grub-splashimages/+bug/6429
[10:24] <Ubugtu> Malone bug 6429 in grub-splashimages "Links to consumed tokens generate 404 errors" [Unknown,Unknown]
[10:24] <mpt> not raining again, is it?
[10:24] <mpt> no, just cloudy, I'll do some laundry today
[10:25] <mpt> BjornT, how does/should someone reject/remove the grub-splashimages line for being irrelevant?
[10:26] <ajmitch> isn't that waiting on the debbugs syncing code?
[10:26] <kiko> not really in that case
[10:26] <ajmitch> since debian tasks were made uneditable a week or two ago
[10:27] <mpt> that one's not linked to any watch
[10:27] <kiko> it's just that grub-splashimages doesn't use malone, right?
[10:27] <mpt> no, it's on the Ubuntu package kiko
[10:27] <mpt> sorry, the Debian package
[10:27] <BjornT> mpt: it's not possible today. i think it should be possible to remove them though, any suggestions how to do it?
[10:29] <mpt> BjornT, perhaps the "Status" area should be two radiobuttons, (*) Automatic  ( ) Not a bug here
[10:29] <mpt> That's a bit lame, but it's early in the morning
[10:31] <mpt> or maybe even a <select> like it is normally
[10:34] <BjornT> mpt: yeah, a <select> is probably better for similarity to normal bugtasks (and it makes the implementation simpler :)). do you know if there's a bug open for this?
[10:35] <mpt> no, but I'll report one if there isn't, just wanted to pick your brain first
[10:35] <mpt> thanks
[10:36] <BjornT> cool
[10:36] <mpt> ah, there's bug 3140
[10:36] <Ubugtu> Malone bug 3140 in malone "Bug watches can't be removed" [Normal,Confirmed]  http://launchpad.net/bugs/3140
[10:36] <mpt> which meant something slightly different at the time it was reported, but is just as valid in the "no watch without a cockfosters" world
[11:06] <kiko> ddaa, push branches are published to bazaar.launchpad.net?
[11:06] <ddaa> yes
[11:07] <kiko> and pushed to that box as well?
[11:07] <ddaa> to vostok, yes
[11:07] <ddaa> hu
[11:07] <ddaa> yes, publishing box is the same as the same as sftp server box (and same as branch puller)
[11:12] <kiko> salgado, how many lines was cprov's soyuz branch when it landed?
[11:15] <salgado> 20k?
[11:16] <kiko> no way?
[11:16] <kiko> seriously?
[11:16] <mpt> cf. my headings branch was 7k (though much easier, of course)
[11:17] <salgado> the diff with context was around that, yes
[11:17] <kiko> soyuz had drug-inspired code inside it mpt
[11:17] <kiko> the most drugs your code has is some diet dr. pepper
[11:17] <mpt> and drugs make everything easier?
[11:17] <kiko> you haven't spent much time around drug addicts, have you?
[11:17] <mpt> I tried Dr. Pepper at Elika's eating club, and didn't like it
[11:18] <mpt> it tastes like marzipan
[11:18] <kiko> it is indeed foul
[11:18] <mpt> I'm an L&P person
[11:24] <ddaa> drugs do not make everything easier, but they make everything else matter less
[11:25] <ddaa> which indeed makes it easier to cope with everything else falling apart
[11:51] <kiko-afk> man, PQM sucks this week
[11:51] <kiko-afk> 100% of downtime so far


 All blue has faded out.
[08:20] <Kilos> hahaha
[08:21] <Kilos> so weird, not even lunch time there and 7.20pm here
[08:22] <paddatrapper> I'm sitting in a lecture theatre for the my supposed third lecture of the day... I have had about 20 minutes of teaching out of 2.5 hours...
[08:22] <Kilos> ouch
[09:12] <inetpro> good mornings
[09:23] <andrewlsd> Morning inetpro and Kilos
[09:23] <andrewlsd> Morning inetpro and Kilos and paddatrapper
[09:24] <andrewlsd> http://www.minetest.net/    server on my laptop at the moment karrimor.duckdns.org:30000
[09:24] <andrewlsd> in case anyone wants to play
[09:32] <paddatrapper> hey andrewlsd
[10:48] <Kilos> hi andrewlsd
[13:34] <gremble> Good afternoon everyone.
[13:34] <gremble> Any news on Kilos?
[14:10] <superfly> Hi gremble, I'm not sure what you heard last. He's at home with his lady and his daughter, but he's not allowed to do anything major.
[14:11] <gremble> Ah okay. That is good news
[14:11] <superfly> Also, the hospital has given them another two weeks to pay
[14:36] <gremble> I hope they are able to manager
[14:36] <gremble> manage*
[16:04] <dlPhreak> Greets
[16:09] <paddatrapper> Hey dl
[16:10] <paddatrapper> dlPhreak too
[16:14] <dlPhreak> paddatrapper: howdy
[18:01] <inetpro> good evening
[18:29] <pavlushka> good evening!
[18:34] <kulelu88> hey pavlushka
[18:34] <pavlushka> Hey kulelu88 :)
[18:34] <pavlushka> ping theblazehen :)
[18:35] <pavlushka> how is it going kulelu88 ?
[18:35] <kulelu88> lekker man howzit?
[19:03] <inetpro> does pavlushka know what lekker means even :-)
[19:03] <kulelu88> oh I assumed he is a local fellow
[19:04] <pavlushka> inetpro: lekker means good I think, but was working on a little :)
[19:04] <pavlushka> on something, so was busy, kulelu88 fine here :)
[19:05] <kulelu88> you speak french? pavlushka
[19:06] <pavlushka> kulelu88: may be someday :p
[19:07] <kulelu88> aah your name 'seems' French pavlushka
[19:08] <pavlushka> kulelu88: really? after this long? when everyone stopped saying that its of Slavic?
[19:08] <kulelu88> forgive my ignorance concerning European names :P
[19:09] <pavlushka> kulelu88: so it seems to you as french, though is more or exactly Russian :)
[19:10] <kulelu88> Vladimir seems more Russian :P
[19:12] <pavlushka> lol
[19:13] <kulelu88> pavlushka: you a software engineer for ubuntu?
[19:14] <pavlushka> kulelu88: I wish :)
[19:14] <kulelu88> We need a wiki of "who is who"
[19:28] <inetpro> kulelu88: he's from Bangladesh if I remember correctly
[19:33] <gremble> Who is you?
[19:33] <gremble> Also, hello
[19:33] <gremble> I think there is one on the ubuntu-za wiki page, kulelu88
[19:34] <kulelu88> ow gremble my man :P #feesmustfallonlybeforefinalexams :D
[19:34] <superfly> o/
[19:36]  * superfly has enough Internets in Struisbaai to get online for a bit
[19:36] <gremble> Just read a letter from Habib that said if there are more disruptions, Wits will close for the rest of the year.
[19:38] <kulelu88> looks like Habib and co. are holding a gun to the students heads now. The hard workers don't want to repeat the year next year
[19:42] <kulelu88> yo superfly howzit?
[19:42] <pavlushka> o/ superfly
[19:42] <superfly> kulelu88: not too bad, and yourself?
[19:43] <kulelu88> good good
[19:43] <superfly> hi pavlushka, shouldn't you be asleep already?
[19:43] <pavlushka> superfly: I forgot, thanks for reminding :)
[19:44]  * pavlushka that's the reason he sleeps in the chair
[19:45] <superfly> not good for your back, pavlushka
[19:46] <pavlushka> point ^
[19:46] <pavlushka> superfly: thanks, at least some one cares about my back :)
[19:47] <superfly> pavlushka: I'm a dad, it's built into me
[19:47]  * pavlushka now leaning back
[19:48] <paddatrapper> kulelu88: problem is the protesters don't care...
[19:48] <pavlushka> hehe, built-in Dad's functions :)
[19:48] <kulelu88> from superfly import Dad
[19:49] <pavlushka> lol
[19:49] <kulelu88> dad = Dad.care(level=9) :P
[19:49] <superfly> paddatrapper: I've actually been idling wondering how many of the protesters are actually students, and also what faculties they're from or what they are studying
[19:51] <paddatrapper> superfly: some aren't, the leaders are UCT students. As far as I know Masixole (the main leader) is a masters student
[19:51] <superfly> ah, so he's not really beholden to the same timelines as the undergrads
[19:51] <paddatrapper> I guess they're humanities students... With some others thrown into the mix
[19:51] <paddatrapper> Yup...
[19:52] <kulelu88> I was about to jokingly say it must be humanities students
[19:54]  * inetpro falling asleep
[19:55] <superfly> inetpro: go to bed, old man
[19:56] <gremble> I'm just glad I've been working on skills that make me employable if it comes to the universities closing :x
[19:57] <kulelu88> if I have a global variable in my code, called "bot", how do I call that variable to my function via a Flask router?
[19:57] <superfly> why do you have a global variable?
[19:57] <gremble> ^
[19:57] <kulelu88> gremble: the closing of the varsities is highly unlikely
[19:58] <kulelu88> superfly: just testing the concept. I will adjust later
[19:58] <kulelu88> this dude in the telegram channel gives bad coding advice :/
[19:58] <superfly> kulelu88: which Telegram channel?
[19:58] <gremble> kulelu88, unlikely it might be, it is still a terrifying prospect to me.
[19:58] <kulelu88> superfly: on telegram itself. for this lib: https://github.com/python-telegram-bot/
[19:59] <inetpro> superfly: heh!
[20:01] <kulelu88> superfly: this is the function: https://www.zerobin.net/?99b16b6bb11140e2#yxO5eeMR744x9ZTC6wrXqMf0KZpX2S5VP8EAxO2GnM0=  . I have removed update. Now I have added a global 'bot' variable. how do I call/use it via a web/curl request?
[20:02] <superfly> ohi ludo!
[20:02] <superfly> kulelu88: yeah, you've got it all wrong
[20:03] <superfly> kulelu88: what he has written there is a framework for writing a bot that listens and responds to messages.
[20:03] <superfly> kulelu88: Flask is a web framework
[20:04] <superfly> now you're trying to mash the two together, and you're not sure why it doesn't work
[20:04] <kulelu88> I am just using Flask for API requests to the bot
[20:04] <superfly> "API requests"?
[20:06] <kulelu88> superfly: I want my server to respond to GET, POST requests, that then pass that on to the bot to perform actions
[20:07] <superfly> like send a message to someone?
[20:08] <kulelu88> superfly: yeah, that is exactly my goal
[20:09] <superfly> hrm, this is interesting. because you've already got an event loop running for the telegram bot, and now you're trying to add an event loop for your HTTP server
[20:11] <kulelu88> superfly: 1 suggestion was to split the REST-server and bot and use the pub-sub of Redis (but that is over-engineering for now)
[20:13] <superfly> kulelu88: you need to forget the extensions part of the Telegram Bot module, and use the plain old API from within Flask
[20:14] <kulelu88> superfly: it does support the regular API stuff too. I could avoid telegram.ext and just use import telegram only
[20:15] <superfly> right, 'cept your example is totally wrong (which is why you're asking)
[20:15] <superfly> kulelu88: that "bot" needs to be created somewhere
[20:15] <superfly> kulelu88: but there's an easy way around this, and we can hook into Python's module loading system for it too
[20:16] <kulelu88> superfly: just before the function, I made the bot here: bot = telegram.Bot(os.environ["API_TOKEN"])
[20:16] <kulelu88> so 'bot' exists
[20:16] <superfly> right, and drop the "bot" from the arguments
[20:17] <kulelu88> oh wow, it worked now :D
[20:17] <kulelu88> darn, web programming is tough :P
[20:17] <superfly> kulelu88: you also have no chat_id
[20:17] <superfly> and "update" shouldn't be there either
[20:17] <kulelu88> it's also stored as a global variable
[20:18] <kulelu88> this lib looks more suited to my needs: https://github.com/datamachine/twx.botapi
[20:18] <superfly> no, the Telegram Bot is fine, it's just engineered to be a Telegram bot and ONLY a Telegram bot
[20:19] <superfly> if you use the extensions
[20:19] <superfly> if you just use the plain old API, then you're fine
[20:19] <kulelu88> superfly: so if I don't include a variable in a function but call a variable that is defined globally, it will fetch the global value of that variable?
[20:20] <superfly> you don't "call" a variable, you just use it
[20:20] <kulelu88> (noob question from hindsight)
[20:20] <superfly> and global means that it is visible everywhere
[20:20] <kulelu88> superfly: and why are global variables dangerous to use?
[20:20] <superfly> because they are visible everywhere
[20:21] <superfly> and one part of the code can change the value without another part being aware of it
[20:22] <kulelu88> noted! alright, no more coding questions :P
[20:22] <superfly> and when you do that with languages like C, where string buffers need to be allocated dynamically, then you get one piece of code reading more memory than it is supposed to
[20:31] <superfly> kulelu88: https://bin.snyman.info/mmmbgq28
[20:32] <superfly> kulelu88: ^^ untested, but I'm sure you can make it work
[20:33] <kulelu88> superfly: so based on your code, I should not try to mesh the 2 together and instead integrate the telegram functions into my Flask REST service?
[20:33] <superfly> yes
[20:33] <kulelu88> I like that solution :thumbsup:
[20:46] <superfly> kulelu88: getting somewhere?
[20:48] <kulelu88> yep, your code is always more legible. I swear you should write a book for imperative web programming! :D
[20:53] <superfly> kulelu88: open a Python prompt, and type "import this" -- I don't need to write a book
[20:55] <superfly> (I'd love to write a book, and self-publish, and become $$$ RICH!!!, but I really don't know what to write about, or how to get people to like my book)
[20:57] <superfly> kulelu88: I also think that knowing the tools and knowing what you are trying to do helps me to bridge the gap and show you how to achieve it
[20:57] <superfly> that largely doesn't work in book format, though
[21:00] <kulelu88> superfly: regular books are terrible, but tutorial-style (eg. let me hold your hand) books sell quite reasonably. Eg. http://nickjanetakis.blogspot.com/
[21:05] <superfly> interesting
[21:07] <kulelu88> but I think gremble has done it already. It's quite a bit of work
[21:08] <gremble> You won't become rich from the book itself. But writing a book is a very good way on expanding your knowledge.
[21:09] <gremble> I would advise against self-publishing though. A good editor is worth more than gold in terms of getting a good quality book out.
[21:11] <kulelu88> gremble: (off-topic) what happens to second semester tests? will the schedule be pushed into December?
[21:12] <gremble> kulelu88, currently the exams have been extended into December.
[21:12] <gremble> I think the last one is written the 6th
[21:12] <gremble> That means supps will be pushed into Jan probably
[21:12] <gremble> With summer school probably touching the start of the first semester
[21:13] <kulelu88> luckily they have such giant gaps between semesters
[21:22] <superfly> gremble: you don't need to use a publisher to get a good editor
[21:23] <superfly> and from all the mistakes I've seen, there aren't many good editors out there either
[21:23] <gremble> superfly, you don't. But a publisher will be your best bet on getting a good one. They don't really sit around :P
[21:24] <superfly> gremble: I've talked to people who have done both, and they say that you can find good editors without needing a publisher
[21:24] <gremble> I agree with that
[21:26] <superfly> heh. my brother had a fight with his English teacher in Std 6, over the spelling of the word "fulfill" - she maintained it was "fullfill" and he said it was the former. they looked it up, and he was right.
[21:27] <gremble> I've had lots of fights with math teachers xD
[21:27] <gremble> Or it could've been the same one each time, I don't know :P
[21:28] <superfly> my maths is terrible, my English is pretty decent
[21:28] <superfly> (decent enough that I'd get maybe 2 or 2 spelling errors in an entire hand-written essay)
[21:28] <superfly> ugh
[21:29] <superfly> 2 or 3
[21:29] <superfly> keyboards are totally different :-P
[21:31] <gremble> These days spelling is not as important as grammar and proper word choice. Some of the stuff that I've edited are the reason I'm getting grey hairs at 25
[21:32] <kulelu88> is or are?
[21:33] <gremble> Where?
[21:33] <kulelu88> "Some of the stuff that I've edited are the reason I'm getting grey hairs at 25" ?
[21:33] <gremble> In the second sentence it can be either, since stuff can be singular or plural. In this case it is plural
[21:33] <gremble> Because I have edited more than one thing
[21:33] <gremble> :P
[21:34] <kulelu88> 1 stuff? isn't stuff plural? (not criticizing, I honestly forgot the rule here)
[21:36] <gremble> Hmm, yes. You are right. You wouldn't use stuff as a singular. But, "The stuff is gone." vs "the stuff are gone"
[21:37] <gremble> So, you can use it as a grouping, where it would act as a singular.
[21:37] <gremble> Language is so much fun :D
[21:42] <kulelu88> the stuff is gone sounds more 'correct', but I'm not sure
[21:43] <superfly> because "stuff" is a collective noun
[21:43] <gremble> Stuff is gone, is the correct one because you are referring to a singular despite it being more than one thing.
[21:44] <gremble> what superfly said :P
[21:44] <superfly> good night everyone, sleepy time for me
[21:45] <gremble> Sleep well superfly