[00:38] <wgrant> Weren't the "technical difficulties" resolved yesterday?
[00:38] <spm> if you mean a somewhat critical server that haemorraged? yeah. whats up?
[00:39] <wgrant> It's still in the #launchpad topic.
[00:39] <spm> haha. thanks! :-D
[00:43] <ajmitch> 'technical difficulties' is such a useful term
[00:43] <wgrant> Yep.
[00:44] <ajmitch> it covers everything from things going a bit slow to the data centre burning down
[00:46] <wgrant> Or just SKS being crap, in this case..
[00:46] <ajmitch> which managed to hold up the appserver?
[00:46] <wgrant> Yes, all of them, I believe.
[00:46] <ajmitch> ouch
[01:00] <mwhudson> it wasn't sks' fault
[01:00] <mwhudson> (this time)
[01:46] <maxb> How long is it supposed to take for Launchpad to notice a new source upload to Debian?
[01:47] <wgrant> It is meant to look twice a day, or maybe four times if the sysadmins have actioned that RT.
[01:47] <wgrant> Note that some appeared to be failing a couple of weeks ago, and slightly over 1% of the archive is currently unimportable because of the format transition.
[01:49] <maxb> It's times like these when it would be handy for the production crontabs to be opensource
[03:08] <thumper> mwhudson: probably not best to reply to Bug 236973 with "oh crap!"
[03:08] <mup> Bug #236973: the interval between launching a new code import job should be more flexible <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/236973>
[03:11] <mwhudson> thumper: no, probably not
[03:11]  * spm subscribes losas to that one
[03:11] <spm> mwhudson: fwiw, that "cheat" in the crontab is evil; so just getting rid of that would be wonderful.
[03:12] <mwhudson> spm: so I guess you wouldn't be super happy for me to suggest fudging it harder?
[03:12] <spm> meh
[03:12] <spm> :-)
[03:13] <mwhudson> thumper: the fix proposed in the description would be very simple and certainly help a bunch
[03:13] <spm> mwhudson: srsly tho - fudge in what way? we could do some things that wouldn't be quite so ... yuk, but still be a fudge.
[03:14] <mwhudson> spm: well, s/sleep 30/sleep 20/ and similar
[03:14] <mwhudson> spm: probably better to do it in the script and avoiding paying the startup cost
[03:14] <spm> 'k. a proper wrapper script vs evil.
[03:14] <spm> right
[03:15] <spm> mwhudson: have we discovered/can-find the actual startup time of the python code to make stuff happen? that'd assist in giving a lower bound.
[03:15] <mwhudson> spm: it's probably 1.something seconds in this case
[03:15] <spm> oki
[03:15] <mwhudson> spm: you could look for the times of the requests to the CodeImportScheduler endpoint on arsenic
[03:16] <mwhudson> that's the first actual useful thing the script does
[03:16] <spm> as an offset from 0 or 30? yeah! good idea!
[03:16] <mwhudson> so if requests come in at xx:xx:05, it's a 5 second startup
[03:16] <spm> nods
[03:20] <spm> mwhudson: eyeball suggests ~ 3-5 secs off :00 and ~ 36-38 off 30 - but I'd suggest the latter is simply due to the effect of the 1st startup etc
[03:20] <mwhudson> spm: right, that makes sense
[03:21]  * spm ponders if breaking out R and Doing It Right is worth it.... ;-)
[03:25] <spm> mwhudson: thinking aloud here - so shoot down if needed - but I wonder if having a random offset sleep wuold be better. eg a random time between 5-15 seconds - would go some small way to avoid the thundering herd of 3 machines all doing the same stuff at the same moment.
[03:25] <mwhudson> spm: yes, that's certainly possible
[03:25] <spm> and being random, would rely on us losas having to sync eg 15 machines down the track with subtle offsets
[03:25] <spm> *wound't*
[03:26] <spm> wouldn't even bleh
[03:26]  * wgrant wonders how they could place so much load on anything in order to make that necessary.
[03:27] <spm> mainly as evetually you will; better to design in the workaround up front
[03:27] <spm> peak loads always bite you hard when you least want them too :-/
[03:29] <spm> esp as these sort of things tend to not impact linearly - more like exponential; (not) literally the straw breaks the camels back
[03:31] <spm> I think it was cnet? one of the big news orgs. in the earlier days of RSS, they used to get *hammered* at specific times. all due to gazillions of teeny trivial requests for rss feeds from clients using the same s/w that was hard wirded to timee X; vs time X + random
[04:08] <mars> so, bug tags don't apply across projects?  I can't click the "yui-3-upgrade" tag to see all problems across all of LP??
[04:12] <mars> ah, to see all of the bugs with a particular tag across projects, I need to search for that tag on the super-project.
[04:24] <mars> jtv, ping
[04:25] <jtv> mars: yes?
[04:26] <mars> hi jtv, just wondering, I need someone to help test the translations JavaScript upgrade on staging.  Would you be willing to do so?
[04:26] <mars> or perhaps volunteer a teammate? :)
[04:29] <jtv> I can help, but hang on
[04:29] <jtv> got a bit of a situation involving contact lenses :)
[04:29] <spm> jtv: you pinged last night? I gather all is solved? or ... ?
[04:29] <mars> :)
[04:30] <jtv> spm: yes, thanks
[04:30] <spm> sweet
[04:33] <jtv> mars: I know one of ours broke with the upgrade (something I wrote in fact), but last night db-devel already had that code changed—by henning I guess
[04:34] <jtv> ahhh! staging's had a code update
[04:34] <jtv> mars: so... what is it you want to test?
[04:34] <spm> jtv: gawd I hope so - it's been runing for long enough.....
[04:34] <jtv> spm: a code update?  I thought those were very lightweight?
[04:35] <spm> was a full one. DB ++
[04:35] <jtv> ah well that takes a while yes :)
[04:36] <mars> jtv, everything in translations that might not be covered by windmill.
[04:37] <mars> jtv, if you do find anything, could you please tag it as "yui-3-upgrade"?  That way we can see what blocker we have for the next rollout.
[04:37] <jtv> mars: ok... we don't have much, so it shouldn't take long
[04:38] <mars> jtv, cool, thank you for the help!
[04:38] <jtv> np
[04:39] <jtv> mars: oh, and there's something unrelated I've been wondering about
[04:39] <jtv> the spinner
[04:39] <jtv> I can see why it's not a sprite,
[04:39] <jtv> but that does mean it can take a while to load
[04:40] <jtv> so what I did on the import queue is put a spinner at the bottom of the page while the JS is setting things up.
[04:40] <jtv> It really helps, but... have I been re-inventing the wheel?
[04:40] <jtv> I should be clearer:
[04:41] <mars> jtv, soyuz had the same problem.  Each page has to decide when to load that image so that it is available.
[04:41] <jtv> I made the JS load the spinner early on (by showing it at the bottom of the page) so that when it's actually needed, it's in the browser cache
[04:41] <mars> At some point, we hit the lower limit of our ability to serve files over-the-wire.
[04:41] <lifeless> mars: well, that limit can be lowered :)
[04:41] <jtv> the lower limit is zero... not sure I follow
[04:42] <jtv> lifeless: GMTA
[04:42] <mars> jtv, once someone caches the spinner, it should be available right away, no?
[04:43] <mars> are you only worried about initial page loads?
[04:44] <jtv> I find the spinner needs to be re-fetched fairly often
[04:52] <jtv> spm: there is something _else_ you could help me with...
[04:52] <spm> jtv: sure
[04:52] <jtv> spm: I need Q/A on a bit of UI that's currently only available to admins
[04:52] <jtv> spm: e.g. here: https://translations.staging.launchpad.net/ubuntu/+source/apport/+custom-language-codes
[04:53] <spm> jtv: so you want rubber ducky to give it a whirl?
[04:53] <jtv> do you see a list there that you can add items to and remove items from?
[04:53] <jtv> I am not familiar with this rubber ducky you refer to
[04:53] <spm> jtv: the rubber duck is the icon of LP admins
[04:54] <spm> https://edge.launchpad.net/~admins
[04:54]  * thumper EODs
[04:54] <jtv> thumper: g'night
[04:54] <spm> jtv: so that came up with "No custom language codes have been defined." and "Add a custom language code " with a green plus
[04:54] <spm> night thumper
[04:55] <spm> selecting the + then gave a list of langs to choose from
[04:55] <jtv> spm: good so far
[04:55] <jtv> spm: maybe I should just join that team... it's got open membership anyway
[04:56] <spm> jtv: whatever you think is best? it's only for a short period anyway :-)
[04:56] <jtv> spm: I was lying for comic effect... it's restricted.  :)
[04:56]  * spm is scored upon. again. :-)
[04:57] <jtv> hardly!
[04:57] <jtv> you didn't throw a tantrum
[04:57] <jtv> (unfortunately, but that's another matter)
[04:57] <jtv> anyway, can you now click into the custom language code you just created to view it?
[04:59] <spm> jtv: https://translations.staging.launchpad.net/ubuntu/+source/apport/+customcode/spm  spm-is-ace (hahahahah)
[04:59] <jtv> mars: I was wondering if maybe we should have some easy-to-use boilerplate for "go fetch my spinner in case I need it later."  To be done at the very end of loading everything else.
[05:00] <spm> jtv: "For apport in ubuntu, uploads with the language code “spm” are associated with the language Acehnese"
[05:00] <jtv> spm: yup, works for me too.
[05:00] <spm> sweet
[05:00] <mars> jtv, I just tried loading the bugs page on edge, and the spinner was cached by the browser.  Of course, that doesn't mean something something else could not be blocking it from rendering instead
[05:00] <jtv> spm: and as is appropriate, I don't see the "remove" link but you probably do
[05:00] <spm> jtv: sure do. give it a twirl?
[05:01] <jtv> spm: oh yes... the red icon shown in the listing, please!
[05:01] <mars> jtv, we thought about that for soyuz, but we did not have a second case for a while.  Bugs also has a spinner, but I don't know if they optimized it as well.
[05:01] <jtv> mars: some pages you end up reloading a lot
[05:01] <spm> jtv: "Removed custom language code 'spm'." == gone
[05:01] <mars> jtv, reloading the page contents, or the spinner graphic?
[05:01] <jtv> mars: the page contents, but my impression was that that made the spinner appear slowly as well
[05:01] <jtv> spm: cool!
[05:02] <jtv> spm: now, the same thing should appear also in a different kind of context:
[05:02] <jtv> https://translations.staging.launchpad.net/expono/+custom-language-codes
[05:02] <jtv> spm: that's a project, whereas the previous one was a package
[05:02] <spm> kk, go thru the same process?
[05:02] <mars> jtv, it could.  Depends on what is in the page.  For instance, putting <script> nodes at the bottom could speed things up.
[05:02] <jtv> spm: please!
[05:03] <spm> jtv: https://translations.staging.launchpad.net/expono/+customcode/spm
[05:03] <spm> will remove on your nod
[05:03]  * jtv checks one little thing first
[05:03]  * jtv looks satisfied & nods at spm
[05:04] <spm> is goné
[05:04] <jtv> spm: and for our last trick, could you verify also that the links to these overview pages appear on the following pages?
[05:05] <jtv> https://translations.staging.launchpad.net/ubuntu/+source/apport
[05:05] <jtv> https://translations.staging.launchpad.net/expono/
[05:05] <jtv> In both cases, the link should be in a little paragraph at the bottom of the right-hand column
[05:06] <spm> jtv: no on the first[1]; yes on the 2nd "If necessary, you may  define custom language codes  for this project."  [1] or I can't find it....
[05:07] <jtv> spm: I always have trouble finding it on source packages myself tbh...
[05:07] <jtv> spm: ah, I think that's because I put it here:
[05:07] <jtv> https://translations.staging.launchpad.net/ubuntu/karmic/+source/apport
[05:08] <spm> right. there it is. same general place as the 2nd
[05:09] <jtv> spm: wonderful!  Another qa-needstesting tag bites the dust
[05:09] <spm> sweet
[05:11] <spm> after that gruelling (***gruelling!!!*** i tells ya!) session of clicking on a web page; /me goes to make a cuppa tea
[05:11] <jtv> spm: thanks!  you've earned it
[05:11] <jtv> just one cookie, mind you
[05:13] <jtv> hey stub
[05:13] <stub> yo
[05:14] <spm> yo stub
[05:14] <spm> jtv: just one? awwww.
[05:15] <jtv> spm: no worries, we'll do more of this some other time and you can have another
[05:15] <spm> oh thankyouthankyouthankyouthankyouthankyouthankyouthankyouthankyouthankyouthankyouthankyouthankyou
[05:16] <jtv> go now, and enjoy your tea
[05:16] <spm> it's seeping as we speak. figured aftr that hard work I needed the stronger one, so went for the assam.
[05:17] <jtv> mars: I just noticed that the notification box for login failure also has that ugly sprites problem
[05:17]  * mwhudson is really severely tempted to switch to gmail for all his mail
[05:17] <mars> jtv, probably present on edge as well
[05:18] <mars> mwhudson, until you have one of those days where it is slow
[05:18] <jtv> mars: I guess... I happened to see it on staging
[05:18] <mwhudson> mars: well what i really want is a desktop client with the good ideas stolen from gmail
[05:18] <mwhudson> i think
[05:18] <jtv> "keep it in beta so people can't complain"?
[05:19] <mars> mwhudson, there was a thread on hackernews about that being the next big thing for the GNU guys, now that they have an OS
[05:19] <mars> not Gmail specifically, but good webapps for personal use
[05:19] <mwhudson> mars: erm, that sounds a little bit like the opposite of what i'm asking for
[05:20] <mwhudson> unless the idea is you run the server on localhost
[05:20] <mars> heh
[05:20] <mars> well, yes.  Or on your personal server
[05:20] <mars> same as people run bip now
[05:21] <mwhudson> of course there's this notmuch thing
[05:25] <mars> notmuch thing?
[05:26] <mwhudson> http://keithp.com/blogs/notmuch/ http://notmuchmail.org/
[05:34] <mars> mwhudson, interesting.  I wonder if the same principle behind sup is how they constructed raindrop?
[05:34] <mwhudson> my turn
[05:34] <mwhudson> mars: raindrop?
[05:34] <mwhudson> oh that
[05:36] <mars> I don't buy into the Raindrop UI changing the world, but the backend has potential as a platform.
[05:37] <jtv> mars: found 1 thing broken with YUI3 upgrade—bug 487428
[05:37] <mup> Bug #487428: Mouse-overs in template links broken by YUI upgrade <ui> <yui-3-upgrade> <Launchpad Translations:New> <https://launchpad.net/bugs/487428>
[05:37] <mars> A simple mechanism for plugging all of your remote accounts into a local datastore, then viewing that datastore with whatever local apps you want.
[05:39] <mars> jtv, ah, that might have been me!  I changed the code to use the new Y.delegate() mechanism.
[05:39] <mars> Saves much processing.
[05:39] <mars> Lacks much testing.
[05:40] <jtv> *cough*
[05:40] <jtv> :)
[05:40] <jtv> spm: are emails not going out?  I tried to reset a password in LP and got no email
[05:41]  * mwhudson wants sqlflakes
[05:41] <jtv> mars: I don't see how anything delegates-related comes in here, so I wouldn't suspect you of this one.
[05:41] <spm> jtv: how long ago? and was it to a gmail and/or hotmail like address?
[05:42] <jtv> spm: twice in the past hour or so, and no.
[05:43] <spm> jtv: worked for me. practically instant.
[05:43] <jtv> gah
[05:44] <jtv> spm: ah, since this was Q/A I was probably stupid enough to do it on staging!
[05:44] <spm> um.... :-)
[05:44] <spm> jtv: s/ignorant/distracted/ ;-)
[05:45] <spm> ignorant/stupid whatever :-)
[05:45] <jtv> very charitable :)
[05:46] <spm> jtv: I can hardly complain. I spent ~ 5-10 mins yesterday wondering why a "tar cf --option tarfile files" wasn't working. face? meet palm.
[05:47] <jtv> spm: not working?  Didn't you get a nice tarfile called --option ?
[05:48] <spm> yes.... it was the "where are the (*&^(*&ing backups?!!?!?"
[05:48] <spm> the error message about "tarfile" being unable to be fstat'ed too was the other weirdness. :-D
[05:49] <mars> spm, how much trouble is it to patch and/or upgrade our AWStats instance?  I would like to track the numbers for Chrome.
[05:50] <spm> mars: no idea. I'd suggest raising an RT
[05:50] <mars> spm, k
[05:51] <mars> ok, I'm done.  Good night!
[05:52] <spm> g'night mars!
[05:52] <jtv> mars: good night!
[05:56]  * mwhudson eods
[05:57] <spm> night mwhudson
[05:57] <jtv> g'night mwhudson
[06:03] <spm> hey al-maisan!
[06:03] <al-maisan> hello spm :)
[06:03] <jtv> hi al-maisan!
[06:03] <al-maisan> how are you?
[06:04] <al-maisan> hello jtv!
[06:25] <stub> Exception: apr-config not found. Please set APR_CONFIG environment variable
[06:25] <stub> Thats a new one today!
[06:30] <stub> Anyone fixing the stable -> db-devel conflict in translations.js?
[06:52] <jtv> stub: I'll take a look, thanks
[07:03] <stub> jtv: I've already got a patch landing - hopefully I guessed correctly ;)
[07:03] <jtv> stub: oh, I just wrote one up as well
[07:04] <stub> looks like it is playing now
[08:53] <henninge> Is anybody onto the "APR_CONFIG" build failure?
[09:02]  * henninge re-runs rocketfuel-setup.
[09:04] <henninge> No joy.
[09:06] <henninge> al-maisan: Did you solve the APR_CONFIG failure?
[09:07] <al-maisan> henninge: unfortunately, no.
[09:07] <henninge> al-maisan: Guten Morge, übrigens... ;)
[09:07] <henninge> n
[09:07] <al-maisan> henninge: Hallo :)
[09:07] <henninge> al-maisan: too bad, I am stuck on that now
[09:07] <al-maisan> henninge: stuck while doing what? "ec2 test"?
[09:07] <henninge> al-maisan: make build
[09:07] <al-maisan> ah
[09:11] <jml> Turn around bright eyes!
[09:11] <jml> uhh, I mean, Good Morning Launchpadders
[09:12] <al-maisan> :)
[09:13] <henninge> Hi jml, great to see you are in a good mood ... ;)
[09:16] <henninge> al-maisan: I just ran update-manager and is *has* an update for libapr !
[09:16] <al-maisan> henninge: oh, what a coincidence ;)
[09:17]  * al-maisan checks on his side
[09:17] <henninge> it's still downloading updates
[09:17] <henninge> oh, and here comes a new kernel
[09:17]  * henninge will have to reboot in a minute
[09:18] <al-maisan> henninge: a new kernel for karmic?
[09:18] <henninge> 2.6.31-15
[09:19] <henninge> yup, "Reboot required"
[09:19] <henninge> al-maisan: back in a sec ;)
[09:19] <al-maisan> henninge: sure, enjoy rebooting :)
[09:24]  * henninge will have to let the filesystem check run through sometime ....
[09:24] <henninge> but there never is time ...
[09:24] <henninge> al-maisan: ok, let's do "make build"
[09:25] <al-maisan> yup
[09:27] <henninge> looking good
[09:27] <henninge> al-maisan: yes, all is well again :-D
[09:28] <al-maisan> henninge: great!
[09:39] <mrevell> morning
[09:42] <al-maisan> Good morning mrevell
[09:49] <jml> mrevell, good morning
[09:50] <mrevell> how's the Pre working out jml?
[09:50] <jml> pretty good so far
[09:50] <jml> haven't yet figured out how to get my mammoth lists out of emacs and onto it
[09:50] <mrevell> I'm sure it won't be long until there's an emacs port for it, heh
[09:50] <jml> also, I had this horrible incident where it borked on upgrade. The guys on #webos were very helpful in getting it back up.
[09:52] <mrevell> Do Pres upgrade over the air?
[09:54] <jml> yes.
[09:54] <jml> except not this one just then :)
[09:54] <jml> brb
[10:03] <mwhudson> al-maisan: ec2 test should select image 110 now, can you try it?
[10:04] <al-maisan> mwhudson: will do.
[10:04] <al-maisan> mwhudson: yes, it's using version 110 now. Thanks!
[10:04] <mwhudson> al-maisan: yay
[10:05] <al-maisan> :)
[10:05] <mwhudson> and i'm glad i checked my mail after getting in tonight...
[10:06] <al-maisan> mwhudson: thank you very much for fixing ec2 test so promptly!
[10:06] <mwhudson> al-maisan: it was just me failing to make it public, i'd already fixed it for me :-)
[10:07] <al-maisan> very nice, we're all benefiting from it now :)
[11:00] <deryck> Morning, all.
[12:58]  * jml lunch
[13:46] <noodles775> Hi leonardr ! When you get a chance, could you read through the comments on bug 487522 and let me know if there's something obvious we missed?
[13:46] <mup> Bug #487522: getPublishedSources() does not support batch operations <Soyuz:New> <https://launchpad.net/bugs/487522>
[13:46] <bigjools> oO
[13:47] <bigjools> james_w has been using that for many months
[13:47] <leonardr> "getPublishedSources()[:10] might not be applying the slice to the server-side query, but rather to the result that never gets back to you"
[13:47] <leonardr> that's correct
[13:47] <leonardr> a python slice is applied to its lhs, and the lhs is not being calculated
[13:48] <leonardr> you need to forgo the syntactic sugar
[13:48] <leonardr> let me find the right syntax
[13:48] <noodles775> leonardr: but https://help.launchpad.net/API/launchpadlib#Collections seems to imply that it works for other CollectionFields?
[13:48] <noodles775> OK, thanks!
[13:49] <noodles775> bigjools: without any args? (ie. ubuntu.getPublishedSources() ;) ).
[13:49] <leonardr> noodles: a lhs like "launchpad.bugs" is resolved without going to the server
[13:49] <bigjools> noodles775: he uses published_since_date IIRC
[13:49] <leonardr> launchpadlib doesn't go to the server until it sees the slice
[13:50] <leonardr> but if you call a named operation, it goes to the server immediately
[13:50] <noodles775> I see. Would it be possible for it to behave similarly for named operations?
[13:51] <noodles775> (at least, if it's followed directly by a slice?)
[13:52] <leonardr> in theory, yes. the function call would return some kind of 'defered' object
[13:56] <leonardr> noodles775: try passing "ws.start" and "ws.size" parameters into the named operation
[13:56] <leonardr> i know that if you send those parameters lazr.restful will respect them, but lazr.restfulclient might reject them because they're not found in the wadl
[13:56] <noodles775> leonardr: thanks! Will do.
[14:00] <jtv> danilos: my near-term fix of choice for that ongoing approver failure is to combine it with bug 487447 by creating a db permissions group for anything that needs to approve translations uploads (instead of duplicating permissions between the branch approver and the regular one).  The real fix is still to factor out that canEditTranslations check from newPOFile though.  OK if I proceed with the first?
[14:00] <mup> Bug #487447: TranslationBranchApprover: permission error on TranslationMessage <oops> <Launchpad Translations:In Progress by jtv> <https://launchpad.net/bugs/487447>
[14:00] <jtv> (Also solves some oopses, which is why I'm working on that one anyway)
[14:01] <danilos> jtv, considering how it keeps coming back, you should know what I am going to say :)
[14:02] <jtv> danilos: "yes, and do the other one after that"?
[14:02] <danilos> jtv, heh, well, something like this, but a bit simpler in terms of effort involved :)
[14:03] <jtv> "delete the whole damn thing"?
[14:03] <danilos> jtv, anyway, we have to talk about the buildfarmjob stuff; have you had a chance to catch up with bigjools?
[14:03] <jtv> danilos: I haven't spoken to him, but did catch up with wgrant and al-maisan
[14:03] <danilos> jtv, yeah, "delete" is much more of what I'd say
[14:05] <jtv> The oopses are not caused by the same root problem, so I still think it makes sense to reorganize the permissions.
[14:06] <jtv> Now, the _testing_ would get simpler if I also remove the pointless check at the same time.
[14:09] <danilos> jtv, it does make sense to re-organize them, but if removing the useless check helps... :)
[14:09]  * jtv grins with blood-lust
[14:09] <jtv> cut!
[14:09] <jtv> hack!
[14:09] <jtv> slash!
[14:09] <jtv> mostly hack.
[14:09] <danilos> jtv, there you go :) traditional hacking is done with an axe, so let's start with that
[14:10]  * jtv grinds
[14:10] <jml> leonardr, fwiw, I've got a branch that splits deferreds out of twisted. that said, it'd probably be nice to have a launchpadlib that did nonblocking IO.
[15:00] <salgado-lunch> sinzui, I think bug 33145 may not have been fixed by the ajax picker, after all. check my comment there
[15:00] <mup> Bug #33145: Cannot submit form if Person requires clarifying without doing a non-obvious no-op <fix-it-friday> <Launchpad Foundations:Fix Released by kiko> <https://launchpad.net/bugs/33145>
[15:01] <sinzui> oops
[15:01] <salgado-lunch> flacoste, re: yui combo loader, is the plan to have it use the minified files or the raw ones?
[15:01] <sinzui> salgado-lunch: Yes, I experienced that problem last week too
[15:01] <flacoste> salgado-lunch: minified files for prod, raw ones for devel
[15:31] <barry> salgado-lunch: ping when you're back, re: bug 482176
[15:31] <mup> Bug #482176: Should be possible to add a member without leaving a team's main page <Launchpad Registry:In Progress by salgado> <https://launchpad.net/bugs/482176>
[15:37] <EdwinGrubbs> bac: ping
[15:42] <abentley> sinzui: I'm in the middle of moving webapp.errorlog into lp.services, and I just came across this comment from you: "XXX sinzui 2008-08-15 bug=258423: We should be importing from lazr.errorlog"
[15:43] <abentley> sinzui: Do you think it makes sense to move errorlog into lp.services?
[15:43] <sinzui> abentley: I am not certain any more. oopses are becoming a lazr lib
[15:44] <bac> EdwinGrubbs: hi
[15:45] <abentley> sinzui: Is someone working on moving oopses into lazr now?
[15:45]  * sinzui thinks
[15:46] <EdwinGrubbs> bac: nevermind, I found the email which explains how to clean the twisted directory.
[15:46] <sinzui> abentley: I recall that u1 and landscape have reworked our oops code. That may only be the backend reporting.
[15:47] <bac> EdwinGrubbs: it is easier now that there is a 'clean' target in sourcecode
[15:47] <sinzui> abentley: I think flacoste/gary know the answers now. I do know that everything in webapp should be errorlog
[15:48] <abentley> sinzui: I don't understand.  Do you mean that everything in webapp.errorlog should be in lazr.errorlog?
[15:48] <sinzui> webapp == lazr
[15:48] <sinzui> abentley: there was a sprint earlier this year that tried to move everything in webapp to lazr
[15:49] <EdwinGrubbs> bac: really? I ran rocketfuel-get yesterday, and I still don't have the clean target.
[15:49] <abentley> sinzui: I don't understand.  Webapp is part of the launchpad codebase, lazr is not, and lazr shouldn't be specific to web AIUI.
[15:49] <bac> EdwinGrubbs: /me looks
[15:50] <bac> EdwinGrubbs: it is in mine
[15:50] <EdwinGrubbs> bac: wait, I was going directly to lp-sourcedeps/sourcecode instead of lp-branches/trunk/sourcecode
[15:50] <bac> ah
[15:54] <sinzui> abentley: we do not want webapp in the launchpad code base. We did not want to write it. We will be happy when that code is out of launchpad.
[15:55] <gary_poster> abentley: (maybe I misunderstand you but) lazr does not contain only web-specific code, but can contain web-specific modules.  I do want our oops generation code, and our oops tools, to be open sourced.  The first will certainly be a lazr.* thing, I think.  The oops tools I'm not as clear on right now.
[15:55] <gary_poster> s/modules/packages/
[15:58] <abentley> gary_poster: I thought sinzui meant that lazr should only be web-specific stuff because he said "webapp == lazr".  I think our expectations of lazr are similar.  I want to hack on our oops generation code, so I'd like to know if anyone else is hacking on it.
[16:02] <gary_poster> abentley: cool.  I don't think so.  matsubara-lunch is the person to coordinate with.  I'm reasonably confident that he's not working on the generation code right now though.
[16:07] <salgado> barry, hi there
[16:08] <barry> salgado: hi.  otp w/sinzui
[16:20] <sinzui> barry: https://edge.launchpad.net/mailman
[16:20] <sinzui> https://edge.launchpad.net/ubuntu/lucid/+source/mailman
[16:24] <sinzui> https://edge.launchpad.net/ubuntu/breezy/+source/mailman
[16:24] <barry> sinzui: skype fail, calling back
[16:24] <sinzui> barry: visit https://edge.launchpad.net/mailman/+packages, then choose the Source package link for each that is wrong
[16:28] <gmb> Does anyone know how to express the following expression using storm: http://pastebin.ubuntu.com/326956/
[16:31] <gmb> I've tried using In(BugSubscription.bug, duplicates_ids) (where duplicate_ids is a list of the IDs of duplicatebugs) but I just get a CompileError.
[16:35] <EdwinGrubbs> gmb: you should be able to use: BugSubscription.bug.is_in(duplicates_ids)
[16:35] <gmb> EdwinGrubbs: Let me try that...
[16:36] <EdwinGrubbs> gmb: you may also add in the subquery as: BugSubscription.bug.is_in(SQL('SELECT id FROM Bug WHERE duplicateof = 15'))
[16:37] <gmb> Eurgh. Let's hope it doesn't come to that.
[16:37] <EdwinGrubbs> gmb: actually, is there a reason you don't use a join instead of a subquery?
[16:37] <gmb> EdwinGrubbs: No reason other than habit
[16:38] <gmb> EdwinGrubbs: Incidentally, I just got "AttributeError: 'Reference' object has no attribute 'is_in'" when using is_in().
[16:39] <EdwinGrubbs> gmb: oh, you have to do: BugSubscription.bugID.is_in(foo)
[16:42] <gmb> EdwinGrubbs: Aha. That's got it. Nice and non-obvious answer. thanks!
[16:45] <sinzui> barry: I was hearing you
[16:46] <sinzui> I hear you
[17:11] <barry> sinzui: i'm back when you are
[17:14]  * jml gone
[18:03] <mrevell> night all
[18:29] <barry> salgado: ping
[18:29] <salgado> hi barry
[18:29] <barry> salgado: hi.  i'm wondering if i should finish up bug 482176 for you
[18:29] <mup> Bug #482176: Should be possible to add a member without leaving a team's main page <Launchpad Registry:In Progress by salgado> <https://launchpad.net/bugs/482176>
[18:30] <salgado> barry, if you'd like, sure!  as I said in my email, I don't think I'll have time for it any time soon
[18:31] <barry> salgado: how close to landing is it?  what still needs to be done?
[18:32] <salgado> barry, it's missing proper handling of two corner cases (currently handled with alert()s) and some windmill tests
[18:34] <barry> salgado: okay.  between that branch and my own, i'm trying to land our sprint branches before i disappear for the long thanksgiving weekend
[18:35] <salgado> barry, cool.  if you don't get to it I'll try to do it on the first week of 3.1.12
[18:35] <barry> salgado: +1
[18:37] <mwhudson> good morning
[19:47] <thumper> morning
[20:20] <sinzui> Chex: ping
[20:39] <thumper> jml: please QA your landings :)
[20:48] <barry> salgado-afk: ping
[20:48] <Chex> sinzui: hello
[20:49] <sinzui> Chex: I need help testing the first item on on this page: https://dev.launchpad.net/RegistryTeam/RegistryTestPlans/3.1.11
[20:49] <sinzui> Chex: Can you create a series on staging and run the initialise-from-parent.py script?
[20:49] <dobey> doh. just missed leonard
[20:49]  * sinzui has no idea how long it takes to run initialise-from-parent.py with real data
[20:51] <wgrant> sinzui: The release process says around eight minutes on production.
[20:52] <bigjools> wgrant: is this the review you're waiting on me for? https://code.edge.launchpad.net/~wgrant/launchpad/distroseries-source-format-selection/+merge/14977
[20:52] <sinzui> wgrant: thanks
[20:53] <wgrant> bigjools: That's the one.
[20:53] <bigjools> ok doing it now
[21:03] <Chex> sinzui: ok, looking.. what kind of a series are you looking for?
[21:03] <sinzui> Chex: create Ubuntu/frumpy and set the parent series to jaunty
[21:05] <thumper> flacoste: call now?
[21:05] <flacoste> thumper: in one hour?
[21:05] <thumper> flacoste: I thought we had moved it forward
[21:05] <thumper> flacoste: however one hour is ok
[21:14] <thumper> barry: ping
[21:15] <barry> thumper: pong
[21:15] <thumper> barry: will mailman strip image attachments throught the LP lists?
[21:15] <barry> thumper: no, but it might hold them for approval if the size of the message is "too big"
[21:16] <thumper> ok, should be pretty small
[21:16] <thumper> barry: total of 25k :)
[21:17] <barry> thumper: that should make it
[21:38]  * thumper turns attention to email
[21:52] <Chex> sinzui: here is the full error I am seeing with this script for you: https://pastebin.canonical.com/25018/
[21:52] <Chex> sinzui: I think its a DB access issue on sourcherry, looking at it now
[21:54] <sinzui> Chex: we may need to pass the config in the environment so that the correct credentials are setup
[21:56] <sinzui> Chex:try prefixing the script with
[21:56] <sinzui>     LPCONFIG=staging;
[21:58] <Chex> sinzui: same thing.  credentials are where I am looking now.
[21:58]  * sinzui thinks
[22:00] <sinzui> Chex: you can use
[22:00] <sinzui>     utilities/lsconf.py -s archivepublisher configs/staging/launchpad-lazr.conf
[22:00] <sinzui> to verify that staging has the information setup
[22:02] <sinzui> well I suppose it does since the user is known. Maybe this cannot be tested on staging
[22:06] <sinzui> Chex: I suspect that dogfood is where archive publishing is tested. If that is the case, I have wasted your time. I will ask someone from Soyuz tomorrow.
[22:06] <bigjools> sinzui: it is, how can I help?
[22:06] <Chex> sinzui: ah ok..
[22:07] <Chex> sinzui: no worries, I learned a little something in the process...
[22:07] <sinzui> bigjools: Chex and I have tried to run initialise-from-parent on staging
[22:08] <bigjools> what happened?
[22:08] <sinzui> bigjools: https://pastebin.canonical.com/25018/
[22:08] <bigjools> db perms
[22:10] <sinzui> looks like that script and lucille have never been tested on staging
[22:10] <bigjools> yeah we usually do it on dogfood
[22:11] <sinzui> Is dogfood up
[22:11] <bigjools> it runs as "lucille" which is obvioiusly not permissioned for the local user
[22:11] <bigjools> it's not :/
[22:11] <bigjools> it's restoring the latest prod database
[22:11] <bigjools> but hs been doing that for 9.5 days now
[22:12] <sinzui> luckilly we have a few months to test my change to initialise-from parent
[22:12] <bigjools> I asked stub to check if I should let it continue or if I should apply his speedup and re-try
[22:12] <bigjools> heh :)
[22:12] <cody-somerville> bigjools, holy crap. its still restoring?
[22:12] <sinzui> and I very confident that it works since the test worked and I ran the script in production
[22:13] <bigjools> cody-somerville: yarp
[22:13] <wgrant> Is dogfood still entirely running on poor old mawson?
[22:13] <bigjools> yarp
[22:13] <bigjools> but there ws a bug in the db restore script that made it slow
[22:13] <bigjools> it normally takes about 1.5 days
[22:13] <wgrant> Ah.
[22:13] <bigjools> ideal to heat the DC over a weekend
[22:14] <ajmitch> if it normally takes 1.5 days, what is 'slow' by those standards?
[22:15] <wgrant> bigjools: Which version is cjwatson's dpkg backport?
[22:15] <bigjools> still going after 9!
[22:15] <ajmitch> it'll finish in another week?
[22:15] <bigjools> no idea
[22:15] <bigjools> wgrant: not sure, you need to ask him
[22:15] <wgrant> bigjools: Will do.
[22:38] <lifeless> spm: lp is rejecting bugmail for me
[22:55] <thumper> lifeless: it doesn't like you any more
[22:58] <lifeless> thumper: oops
[23:04] <spm> lifeless: that's a cool trick. have you any examples you can show?
[23:05] <lifeless> spm: I deleted them, but its logged mail oopses
[23:07] <spm> oki
[23:37] <bigjools> good night everyone