[12:12] bradb, yeah, but I think I still would prefer seeing createBug modified. [12:12] that way this comes across as less of a hack [12:12] (for one, you would only need one if clause) === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [12:15] kiko: hm. it seems to me that getting that right shouldn't up to the caller though. i.e. the API should abstract away the concern of making sure someone (the .bugcontact or .owner) is subscribed to private bugs. [12:15] my other branch does that [12:16] what do you think? should the API rely on passing the correct subscribers for what the UI presents as a "built-in" part of the model? === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [12:17] bradb, well, hmmm. [12:18] so you're saying that the back-end will know who to subscribe depending on privacy/security settings? [12:18] kiko: yep [12:19] I made an API change to createBug in my other branch, collapsing security_related and private into just security_related, just like the UI presents that model, that I think will bite me now, but I can fix that on that branch. (I'll have to, to keep my tests passing.) [12:27] bradb, I think the safest way forward [12:27] is to not modify createBug other than allowing specifying subscribers [12:27] and then do everything in the browser code [12:31] sorry, phone [12:31] bradb, I think it's best not to [12:31] collapse [12:31] sure [12:34] kiko: is there a need to specify subscribers though, for our immediate use cases? the way it is now (even after uncollapsing the createBug flag back into two) is that you only have to worry about passing it the right values of security/privacy and the API will do the work for you. [12:34] that way it's consistent wherever it's used, e.g., email, xmlrpc, etc. [12:35] hmmm. [12:35] you actually have a good point there [12:36] the multiple interfaces [12:36] so tell you what -- I can't answer this today, my head is busy with my own code [12:36] but tomorrow first-thing I'll look at both patches [12:36] fair enough [12:37] but, maybe i should ping you on that tomorrow then, cause i'll need about 30 mins to uncollapse the flags to .createBug on the other branch === mpt_ [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad [12:44] kiko: i moved my other branch into your queue, and put the landscape hack in there too. i'll followup tomorrow morning. thanks! === bradb tunes out of IRC [12:45] cool [01:09] man bzrlib tests hate me === LeeJunFan_ [n=junfan@adsl-69-210-207-5.dsl.klmzmi.ameritech.net] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === thierryn [n=thierry@modemcable251.69-131-66.mc.videotron.ca] has joined #launchpad === rpedro_ [n=rpedro@87-196-104-130.net.novis.pt] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"] [04:05] jamesh: so yeah, asterisk [04:06] lifeless: what about it? [04:06] do you have a local server ? [04:06] no. [04:06] Ekiga was able to talk to voip.canonical.com through my NAT firewall okay [04:07] (an linux iptables firewall allowing outgoing connections) [04:12] I can connect to 6701 ok, but I only get static back [04:13] also, my registration do-dad fails [04:15] is your sip running ? [04:15] It is now [04:15] I'll try calling [04:16] sip:7543@canonical.com [04:16] not available [04:16] it crashed [04:17] ha! [04:17] try again === stub [n=stub@ppp-58.8.1.197.revip2.asianet.co.th] has joined #launchpad [04:18] are we connected ? [04:19] I heard about .5 seconds that might be you [04:19] I've just said a few sentences [04:19] I could hear you saying something but couldn't make out what it was [04:19] I heard 'can you hear me speak' [04:20] and possibly keys [04:20] but just static for the rest [04:20] I just said hello four times [04:20] I'm hearing "pulses" of audio [04:21] I just badly quoted the quick brown fox thing [04:21] did you hear any of it ? [04:21] it's like I get every second half second of your audio (or something like that) [04:21] in fact, I know, I'll read the voip setup page to you [04:22] I just read the first section [04:23] have you turned silence detection off ? === stub prepares for the production update [04:23] I heard some of what you were saying === jsgotangco [n=jsg123@210.4.38.43] has joined #launchpad [04:23] it wasn't on when I checked [04:23] but its like it fades out and then I get static [04:25] I'm not hearing any speech at the moment [04:25] I' [04:25] m not speaking [04:26] hang up and I'll try calling you [04:27] I cannot register properly :( [04:27] but try anyhow [04:27] both spiv and me tried shtoom too, without success (complains about some unexpected packet or something) [04:29] did you try to ring ? [04:29] yeah. It went through to your voice mail [04:29] can you do me a favour [04:29] go to accounts, properties of your canonical account, more options [04:30] and tell me the realm [04:30] sip:7543@canonical.com [04:30] it got filled in automatically when I connected the first time [04:30] yes [04:30] the 'realm' is your sip account ? [04:30] seems to be [04:31] stub, was the rollout today postponed? [04:31] Gooooooooooooooooood afternoon Launchpadders! [04:32] kiko-zzz, [01:20] I got distracted and missed todays rollout. Anyone going to cry if I put it off until tomorrow quiet time? [04:33] kiko-zzz: Rollout my yesterday was postponed, rollout today is being kicked off right now [04:33] Get with the timezone, you are living in the past ya hippie! [04:34] jamesh: so, I've filed an RT request on my login. [04:35] trying a different sound card [04:35] kiko-zzz: r3758 before you ask, as discussed with matsubara [04:36] rtp drops packets failry regularly when ou overcommit [04:36] so bandwidth - as long as we are 'in the ballpark' is usually fine [04:37] the GSM codec seems to be doing a better job than the PCMU codec (that was picked before) [04:37] I've also changed setup [04:37] I'm using a builting sound card rather than an external [04:38] but its not good enough yet :) [04:38] so, lets swap cards back, no other changes, see if it stays better/worse [04:38] can you try saying something again? [04:39] did it crash ? [04:39] ok, my usb headset is art of the problem for incoming audio for me [04:40] no. I was trying to get a recording so you could hear what you sounded like [04:40] ah [04:40] lifeless: Is there some magic on balleny making new branches and commits to the rocketfuel archive on balleny automatically get pushed to chinstrap? [04:40] stub: the push is done by pqm [04:41] ok. One less step to remember. I was wondering why pushing a fresh production branch pushed 0 revisions ;) [04:42] stub: if you want to do it by hand, just do it by hand - bzr push sftp://chinstrap/home/warthogs/archives/rocketfuel/.... [04:42] stub: how are you making the production branches ? [04:42] cd ~pqm/archives/rocketfuel/launchpad/production; bzr branch -r xxxx ../devel 1.xx [04:43] you just made 1.68 [04:43] ? [04:43] Yes [04:43] bzr info | grep publish [04:43] will tell you where it is set to push to [04:43] the reason it says '0 revisions pushed' is because of a bug in bzr [04:44] which is fixed in recent bzr [04:44] ok. So I need to manually push production branch updates to chinstrap? Or not? [04:45] if you do them by hand, push them by hand [04:45] but the only thing that you need to do by hand is the branch creation [04:45] after that, pqm can handle it all for you [04:45] pqm can handle cherry picks now? [04:46] erm, no. [04:46] the only TWO things you need to do by hand ... [04:46] ok :) [04:46] (unless you make a short branch with the cherry pick, and ask pqm to merge the entire branch) [04:46] which is what I would do [04:48] Which means I won't need to disable pqm, which means I won't forget to reenable it ;) [04:48] :) [04:48] jamesh: so, how about this [04:49] I ring you on ekiga [04:49] I ring you on your landline [04:49] then talk into one, listen on the other ;) [04:49] and I can let you hear how you sound [04:50] okay [04:50] whats the best landline to ring you on? [04:52] I /msg'd you the number === stub showers and heads of for breakfast [04:52] not all that bad [04:52] listen to this thought [04:53] I'm going to put mylandline against hte headset [04:53] you speak anytime [04:53] can you hear the ripple? [04:53] yup [04:54] any more tests you can think of? [04:54] actually, I do have one more test [04:54] conf call [04:54] oh, hang on [04:55] Ekiga appears to be a timesink :-/ [04:58] I've tried to get in to the conf call [04:58] cant tell if I mad eit [04:59] I heard the "new participant tone", and can hear a similar ripple static effect [04:59] sounds like I'm in :( [04:59] does that help the ripple? [05:00] not really. [05:00] the conference call line was silent til you joined [05:00] better ? [05:00] yep [05:00] can you try speaking? [05:00] ok, thats gain on the microphone [05:01] I am saying testing testing 1 2 3 [05:01] if you are sayin anything I cant hear it [05:01] I cannot hear myself even [05:02] ok I'm hearing testing 1,2,3 [05:02] I can hear that but the audio is very bad (about the same as the non-conf-call) [05:02] with extra ripple [05:02] can you hear me now? === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad [05:02] I think the ripple is distortion [05:02] I can just make it out [05:03] I am guessing that any noise is transmitted and the ripple introduced by $something [05:03] I was getting much better audio with steve/stub/spiv on monday, so I wonder if it is something with your link? [05:03] (or maybe something else has changed? [05:03] jamesh: who knows :( [05:03] I'm going to try linphone now [05:04] can you keep ekiga running ? [05:04] yep. [05:04] I'm still in the conference call [05:24] jamesh: can you hang up on that [05:25] okay. I've hung up [05:25] is it any better ? [05:25] yes [05:25] cool [05:25] you sound like shit still :) [05:26] I can understand you now (which is good), but the sound quality isn't that great [05:26] clearly better than before :) [05:26] you are rippling badly [05:26] I can *just* make it out [05:26] what did you change at your end? [05:26] kphone rather than ekiga [05:26] took a little guesswork to get it running [05:27] could you ring me [05:27] rotfl [05:27] ok, it answered [05:27] then blew up [05:27] hmm, this is interesting [05:28] I had an asoundrc file [05:28] asoundrc files seem to be evil [05:29] entirely [05:29] but I might just be superstitious [05:29] try ringing me ? [05:29] this is ekiga agaon [05:29] *again* [05:29] crap again [05:29] ditto [05:30] yeah [05:30] but if we can get better it wont cause headaches [05:31] can you head me ? [05:31] I heard something and then nothing [05:31] can you speak ? [05:31] I am now [05:31] I'm hearing nothing :( [05:31] run gme ? [05:31] gme? [05:32] ring me :) [05:32] I can you hear you [05:32] can you hear me ? [05:33] it is like it was earlier: too broken up to understand [05:33] argh [05:33] well, at least ekiga has decided to register now [05:34] hhhhaaa [05:34] my bandwitdh use is at 100% [05:34] 1349.449356 82.211.81.194 -> 192.168.1.5 SIP Status: 401 Unauthorized [05:34] 1349.450587 192.168.1.5 -> 82.211.81.194 SIP Request: CANCEL sip:RobertCollins@voip.canonical.com [05:34] 1349.452665 192.168.1.5 -> 82.211.81.194 SIP Request: SUBSCRIBE sip:RobertCollins@voip.canonical.com [05:34] 1349.507049 82.211.81.194 -> 192.168.1.5 SIP Status: 200 OK [05:34] 1349.575274 82.211.81.194 -> 192.168.1.5 SIP Status: 401 Unauthorized [05:34] 1349.576474 192.168.1.5 -> 82.211.81.194 SIP Request: CANCEL sip:RobertCollins@voip.canonical.com [05:34] 1349.579509 192.168.1.5 -> 82.211.81.194 SIP Request: SUBSCRIBE sip:RobertCollins@voip.canonical.com [05:34] 1349.634694 82.211.81.194 -> 192.168.1.5 SIP Status: 200 OK [05:35] and now ekiga sulks again [05:35] I was able to register with shtoom today [05:36] argh. "[shtoom.rtp.protocol.RTPProtocol (UDP)] received packet with unknown PT 1" errors still [05:36] heh [05:37] well, thats enough of my life on this [05:37] I'll wait for the admins response [05:37] lunchtime === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === rpedro_ [n=rpedro@87-196-32-244.net.novis.pt] has joined #launchpad === Fujitsu [n=Fujitsu@c211-28-181-26.eburwd7.vic.optusnet.com.au] has joined #launchpad === mpt__ [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad === stub [n=stub@ppp-58.8.1.197.revip2.asianet.co.th] has joined #launchpad === mpt_ [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad === rpedro_ [n=rpedro@87-196-75-66.net.novis.pt] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === carlos [n=carlos@35.Red-88-15-199.dynamicIP.rima-tde.net] has joined #launchpad [09:05] morning [09:07] hi [09:18] morning [09:51] BjornT: https://launchpad.net/products/malone/+ticket/1179 [09:51] BjornT: It seems I should retarget the bugtasks associated with Ubuntu Edgy, but I'm not sure about bugtasks associated with just Ubuntu. [09:55] Which I guess is important, as there are 466 associated with just Ubuntu and none associated explicitly with Edgy. [09:56] I suppose they should all be reassigned. [09:57] stub: right, that's a bit tricky since we don't have good release targeting yet. but as you say, they should all be reassigned since atm we use mostly non-release-specific tasks to track bugs. [09:58] Only those that are not Rejected or Fix Released? [09:58] Or those statuses too? [10:02] well, it really depends on when they were rejected or fixed... maybe you should start with retargeting only the open bugs and see if someone complains? === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [10:04] It's just me or chinstrap is ignoring any ssh certificate? === frodon_ido [n=patrick@ip-213-49-212-229.dsl.scarlet.be] has joined #launchpad [10:14] BjornT: ping, please review bzr-native today [10:14] otherwise, I won't be able to handle it before tuesday [10:18] ddaa: sure, i was planning to do it today. === mpt__ [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad === malcc [n=malcolm@host86-134-233-12.range86-134.btcentralplus.com] has joined #launchpad [10:37] stub: do have time to take a look at https://launchpad.canonical.com/SimpleBugKeywords? (there's an XXX for you in the Implementation section) === stub has a quick look === stub and a slow page load :-/ === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [10:41] BjornT: We only want to exact matching on tags? So searching for 'laptop' will not match the 'laptops' tag? [10:43] If so, the best implementation would be a three column BugTag table containing just (id serial, bug int, tag text) [10:44] Searching would involve adding this table into the existing disgusting search query as an outer join using simple string matching. [10:44] Tags should be automatically converted to lowercase and stored that way. [10:44] stub: well, there are two cases. we want to be able to limit the search on a specific tag, then i'd say we want exact matches only. but if you type in 'laptop' on the +bugs pages, matching the 'laptops' tag is ok, but not necessary. [10:45] I think we want exact matching on tags [10:46] yeah, that makes sense. [10:46] esp. as the UI might end up being a select box [10:48] I'll add the relevant indexes when reviewing the db patch. I think we will need to but might be able to get away with one. [10:48] c/to/two [10:49] BjornT: That all you need from me? [10:50] stub: yes, i think that was all, thanks. [10:50] last time I looked at the search code it seemed to be straining at the seams and about to explode (I was looking at adding in comment searching). It might need some refactoring :-( [10:51] yeah, it's quite icky.... how would you refactor it? === doko [n=doko@dslb-088-073-107-122.pools.arcor-ip.net] has joined #launchpad [10:51] It might be worth constructing a view and searching that for distinct bug id's. === marcus_notebook [n=mholthau@251.26.203.62.cust.bluewin.ch] has joined #launchpad [10:52] Nah... the reason it is 'icky at the moment is to avoid joining tables that are not needed for the current query. [10:53] I have to head of for a bit anyway [10:53] ddaa: could you send me a diff of the bzr-native branch? the pending-reviews page is down. [10:54] sure [10:54] thanks [10:59] BjornT: sent [10:59] SteveA: hi, got a sec? [11:01] mpool: hello [11:03] mpool: want to talk using the new canonical sip thing/ [11:03] ? === mpt_ [n=mpt@203-173-177-223.bliink.ihug.co.nz] has joined #launchpad [11:07] SteveA: ah, i haven't managed to successfully register yet [11:07] not sure if it's a problem on the server or with my network [11:08] then skype? === ogra [n=ogra@ubuntu/member/ogra] has joined #launchpad [11:10] hi, i got a little problem with a bzr checkout from LP [11:10] i ran bzr checkout sftp://ogra@bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/edubuntu.edgy which worked fine [11:11] mpool: ping [11:11] after that i ran bzr checkout sftp://ogra@bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.edgy [11:11] SteveA: hi, just talking to robertc [11:11] maybe tomorrow or later? [11:11] which now results in: ssh: connect to host bazaar.launchpad.net port 22: Connection refused [11:12] mpool: okay, tomorrow is fine with me [11:12] ogra: there was recently a bug where sftp urls need a trailing slash [11:12] i think that's fixed in .dev but you might still have it [11:12] i'll try that ... [11:13] mpool, i just heard we have general ssh probs ... i'll come back if that doesnt solve it [11:13] telsteve@einheit:~$ telnet bazaar.launchpad.net 22 [11:13] Trying 82.211.81.254... [11:13] telnet: Unable to connect to remote host: Connection refused [11:13] [11:13] it's a lower level problem [11:13] Someone Else's Problem [11:16] spiv/lifeless/stub: ? [11:16] never mind [11:20] stub: I think I found and fix teh problem with posubmission duplicates [11:20] stub: but I cannot test it until I get access to our DC, I will do a full run on staging and try to set the 'unique' restriction to be 100% sure it's working now [11:21] ok, change my mind, I definitely need spiv/lifeless/stub [11:27] BjornT: if you have some time this afternoon, I'd like to have a call about https://launchpad.net/products/launchpad-bazaar/+spec/vcs-imports-ui-test-plan [11:27] Leave for family lunch now [11:27] * Leaving [11:32] ddaa: gone already? [11:32] Almost [11:32] got to catch a bus === ddaa runs for his bus === jamesh [n=james@203-59-20-109.dyn.iinet.net.au] has joined #launchpad [11:36] blah [11:38] elmo: ? [11:39] elmo: if you add ':' it highlights the channel :) [11:39] lifeless: I rebooted vostok, restarted the push sftp server, but it's listening on the wrong port [11:39] elmo: wrong IP or wrong socket [11:39] or btoh ? [11:39] well, kind of both [11:39] it's listening on 0.0.0.0:5022 [11:39] should be on 82.211.81.254:22 [11:39] funky do-dah [11:40] and ssh in there is still a bit whacky right ? [11:40] nevermind, just my link going spastic [11:41] ssh to vostok itself is about the only working ssh in the DC right now ;-) [11:41] meepification [11:41] how did you start it ? [11:42] sudo su - supermirror, ./start-bzr-sftp [11:43] config.supermirrorsftp.port is the magic, lets see [11:44] you might have to set LPCONFIG to something [11:44] jamesh: indeed, but its meant to be set by the script [11:44] to avoid forcing huge amounts of cache into the sysadmins heads [11:44] and indeed, that would appear to be AWOL [11:46] elmo: look better ? [11:46] tcp 0 0 0.0.0.0:5022 0.0.0.0:* LISTEN 7768/python [11:46] nope === mdz_ [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad [11:47] oh, foo [11:48] are you sure there is not an init script ? I swore that we made one [11:48] anyhow, fixing for real I think [11:48] fixed I think [11:49] that script could not have been working though, so there must have been another way of starting it :) [11:49] oh, crap there is [11:49] sorry, I thought I looked for one [11:49] shall I see if it works? [11:49] lets do that [11:49] (I have no idea why it didn't work on boot) [11:49] and if it does rm that start-bzr-sftp [11:49] you drive, shout if you want me to peek [11:50] yeah, script works fine [11:50] removed that file [11:50] heh [11:50] I'll investigate later why it didn't work after boot [11:50] sorry [11:50] np [11:50] whats the script name ? [11:50] /etc/init.d/bzr-sftp [11:51] (stub and I need to run it to bounce the server during upgrades) [11:51] danke [12:03] carlos: ? [12:05] elmo: hi === jinty [n=jinty@213-156-52-99.fastres.net] has joined #launchpad [12:09] carlos: I need to kill mawson [12:09] can I kill your cronjob ,or is it life-endingly important? [12:10] elmo: kill it, I will execute it later [12:10] thanks [12:11] ddaa: sure, i should have time for a call later. === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [12:51] I'm going to be offline for a while, to get some coding done. Send me a txt message or phone if you need something urgently. [12:55] LP is going down in 15 minutes, ETD is 10 mins [01:16] LP is back, yell if stuff doesn't work === rpedro [n=rpedro@87-196-109-13.net.novis.pt] has joined #launchpad [01:36] *.ubuntu.com, launchpad.net etc. are disappearing for a couple of minutes for some essential maintenance === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === danilos [n=danilo@82.117.204.45] has joined #launchpad [01:41] danilos: hi [01:41] carlos: hi [01:41] how's going? [01:41] carlos: I am having some problems with launchpad schemas [01:42] I can't set the database up [01:42] danilos: what's the error you get? === jd_ [n=jd@wikipedia/Meanos] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === jinty [n=jinty@213-156-52-99.fastres.net] has joined #launchpad === jd_ is now known as jd_miam === stub [n=stub@ppp-58.8.1.197.revip2.asianet.co.th] has joined #launchpad === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === jd_miam is now known as jd_ === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === bradb [n=bradb@modemcable048.58-130-66.mc.videotron.ca] has joined #launchpad === thierryn [n=thierry@modemcable251.69-131-66.mc.videotron.ca] has joined #launchpad === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [03:06] stub, around? === rodarvus [n=rodarvus@ubuntu/member/rodarvus] has joined #launchpad [03:08] good morning [03:09] there is a LP account called 'rodarvus', which apparently was automatically created long ago, when translations were imported into Rosetta [03:09] (these translations were done by me, many years ago) [03:10] I wonder if it is possible to merge this account into my current LP account 'rodrigonovo' [03:10] I mean, in other words, if it is possible for me to use 'rodarvus' as LP account, inheriting all history my current account already has [03:11] rodarvus: yes, that's possible [03:11] rodarvus: I guess you have control over the email addresses in both accounts, right? [03:11] no, I don't have control over 'rodarvus' [03:12] it was apparently automatically created [03:12] rodarvus: but it has an email address associated [03:12] oh? [03:13] https://launchpad.net/people/rodarvus says nothing about email addresses [03:13] rodarvus, I think I can find the email address associated with it. [03:14] all launchpad accounts have an email associated with them. sometimes they're not validated, and thus won't be shown [03:14] rodarvus: you can also try to merge it from: https://launchpad.net/people/+requestmerge [03:15] rodarvus, it's your email @conectiva that is associated with that account [03:15] but that will migrate all info from rodarvus into rodrigonovo [03:15] salgado: right, as I said [03:15] I last owned this email 6 years ago [03:15] you don't have access to that anymore? [03:15] instead of rodrigonovo into rodarvus [03:15] so I surely didn't created this account myself :) [03:15] in that case we need a launchpad admin [03:15] salgado: this email doesn't exists anymore - since six years :) [03:16] long before LaunchPad was created, I think :) [03:16] salgado: who should I contact for that? === carlos -> lunch [03:17] rodarvus, any of the members of https://launchpad.net/people/admins [03:17] rodarvus: https://launchpad.net/people/admins [03:17] rodarvus, kiko, SteveA or stub [03:17] salgado, carlos: thanks! [03:17] preferably then, I mean [03:17] *nods* [03:21] salgado: yo [03:21] hi stub. I wanted to check with you when your shipit constraints branch went to production, if it already went [03:21] I was about to ask the channel.... [03:22] Is anyone going to cry if the production rollout is delayed a second day until tomorrow? Todays rollout didn't happen during quiet time due to problems on the LAN. [03:22] salgado: No export has been run yet today btw. === Fr33k^oN [n=as@88.222.160.178] has joined #launchpad [03:22] (and no complaints in the mailbox!) === niemeyer [n=niemeyer@200.138.43.81] has joined #launchpad [03:25] stub, can you run https://chinstrap.ubuntu.com/~dsilvers/paste/fileBuwnLM.html on production, to see if the postcode problem will bite us today? [03:27] slow query.... [03:28] spiv, I guess my real-karma-context branch is approved? [03:30] stub, anyway, I think we can fire the export script. there shouldn't be many postcodes causing problems and we can easily fix the csv after the export, if needed [03:30] Once we know what they are [03:30] we can even find them in the CSV [03:30] salgado: yes :) [03:31] the problem happens when importing the CSV in OpenOffice [03:32] ahh... ok. Export running now anyway. === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [03:33] stub, cool [03:41] morning! [03:42] stub, how does my makefile patch look? === rodarvus [n=rodarvus@ubuntu/member/rodarvus] has left #launchpad ["Leaving"] [03:45] I'll have a look now, but I suck on Makefiles [03:45] I don't know if spiv did any work on that today - I assigned him to the spec this morning. [03:46] erm... yesterday. forget time. [03:46] stub, the changes are pretty simple [03:46] looks fine [03:47] r=stub [03:47] okidok [03:47] let me try and land that then [03:47] lifeless gave me permission to update pqm.conf too (although he might want to do it if he is still around) [03:47] stub, I'll ping or email you when it lands so you can click it then === jinty [n=jinty@213-156-52-99.fastres.net] has joined #launchpad [03:54] BjornT: can we have a call soon? [03:54] man bzr is fast [03:55] kiko: no, it's just less slow than it used to be ;) [03:55] no, it's blazingly fast [03:55] BjornT: I would like some guidance and sanity checking on https://launchpad.canonical.com/VcsImportUiTestPlan [03:55] kiko: there was an upgrade recently? [03:55] not sure [03:56] but working with sqlobject is just so trivial with it now [03:56] oh right [03:56] it used to be fast [03:56] this sort of small branch are fast [03:56] but it is now VERY fast [03:56] salgado: export is done if you want to check it [03:56] stub, thanks, I'll do that [03:56] for a lot of ops, a significant factor is the ~0.5s it takes to start python and load the modules... [03:57] kiko: you could get more snappiness using bzr service or bzr shell [03:57] what's that? [03:57] plugins [03:58] what do they do? [03:58] ah, run bzr as a service? [03:58] avoiding startup time? [03:58] bzr service is an horribly insecure prototype that sets up a bzrlib runner listening to a socket [03:58] heh [03:58] and an ultra-thin commandline client in C [03:59] bzr shell is the spiritual son of aba, tlash, etc. [03:59] stub, did that query finish or you stopped it? [03:59] salgado: still running [03:59] (told you it was slow!) [03:59] a simple shell that runs a REPL in python, so you do not have to type "bzr" and so you do not have to spawn python for every command [03:59] wow, that is really slow. :-( [04:00] non-trivial shell commands are handed down do the system shell [04:00] I'll kill it anyway [04:01] hey guys, do I have to restart launchpad whenever I change anything in the code? or is there an easier way to refresh stuff? (removing .pyc didn't help) [04:02] danilos, you have to restart. [04:02] there is no easier way [04:02] kiko: ok, thanks [04:02] danilos, reevaluating the code that was modified is a non-trivial enterprise [04:02] stub, what of https://launchpad.canonical.com/LaunchpadProductionStatus ? [04:03] python is not yet quite OO enough to allow on comfortable on-the-fly modification of classes [04:03] ddaa, it doesn't have to do exclusively with OOness though [04:03] kiko: yeah, but I was thinking of some slower-non-production-debug-mode or something ;) [04:03] ddaa: sure, we can have a call. how about in 15 minutes? [04:03] ddaa, because I once did implement something like this using twisted's reload functionality [04:03] hu [04:03] ddaa, but there's a lot of complexity [04:04] kiko: would you have time for a call today to discuss https://launchpad.canonical.com/SimpleBugKeywords? [04:04] in particular in swapping running instance's classes, etc. [04:04] BjornT, sure! [04:04] I do not know the issue deeply enough to argue, but I expect a lot of the functionality comes from quirks in the python object model [04:04] kiko: That is all still valid except for the scheduled update time. Skipped rollout today again due to problems on the LAN. I can update now if there is urgent stuff, but nobody appears to be in tears. [04:04] a lot of the _complexity_ [04:04] stub, no, I was just curious [04:04] cprov: can you or anybody else than infinity hand-build a package on a buildd? [04:04] ddaa, few OO languages allow you to swap an instance's class in runtime :) [04:04] kiko: thanks! i'll ping you after the call with ddaa. [04:05] sure thing [04:05] gotta learn smalltalk to talk like a real oo programmer :) [04:05] doko: uhm, what do you mean by hand-build, a package not submitted via soyuz ? [04:05] So far, in my naive world view, Smalltalk is still "as much OO as can be, and maybe still a bit more" [04:06] a bit like forth and Scheme, take a simple idea, and push it to extremes [04:06] ddaa, that indeed is naive, because every time I used smalltalk it came across as a toy language :-P [04:07] kiko: some guy who made a keynote at EP would disagree with you ;) [04:08] BjornT: okay [04:09] cprov: need to build a new gcc-4.1 using binaries which I built myself. so what needs to be done: a) install my binaries on the buildd, b) build gcc-4.1, c) install the just built binaries on the buildd, d) build gcc-4.1 again, e) upload gcc-4.1 [04:09] cprov: we only need that on powerpc [04:09] doko, why using these specific binaries? [04:10] kiko: because the binaries in the archive are broken [04:11] doko: it looks scary, even if I can do this I should not, can we wait infinity ? [04:12] doko, and the chroot is busted? [04:13] cprov: sure, we can ... but I would like to have exception handling again [04:13] s/again/working again/ [04:14] kiko: gnat-4.1 is busted [04:14] gcc-4.1, libgcc1 [04:15] doko, and they are unable to bootstrap a new gcc compile, is that it? [04:16] doko: how do you mean ? are you suggesting we should support this kind of workflow ? can't you solve this by having a special chroot with your binaries installed ? [04:17] cprov, I think the problem isn't in the chroot, but in the archive itself [04:18] kiko: yes [04:18] kiko: the chroot would have the newer/correct version of the broken binaries [04:18] cprov, does the chroot contain gcc binaries? [04:19] kiko: no, but we can install them ;) ... okay maybe I'm suggesting blue-sky stuff, nevermind [04:20] cprov: well, if you do want to define a workflow for such situations ... it's basically: use untrusted binaries, then build the new binaries (which are then trusted), install them, then upload. not sure if it's worth to automate that [04:21] doko: is there something we can do to fix the archive w/o rebuilding the package ? was it a soyuz failure in you POV ? [04:22] kiko: Smalltalk == toy will get you a lot of agreement, although not from me, but it doesn't contradict Smalltalk == Very very very OO, which is true whichever way you slice the toy thing [04:22] cprov: no, wrong package; but I need gnat-4.1 to build gnat.4,1 ... [04:23] doko: not sure about how we would install the untrusted binaries if not manually in the chroot itself, but the rest is supported. === [PUPPETS] Gonzo [i=gonzo@80.69.47.16] has joined #launchpad [04:27] ddaa: i'm ready now, should we have a call? [04:27] sure [04:27] sip, skype or normal phone? [04:28] grah [04:28] ekiga is one of those goddamn braindead app that confuses my ctrl-A for ctrl-Q... [04:29] BjornT: let's give sip a try, I was able to have a successful conversation with the echo server and the voicemail before. [04:29] I just need to refrain from ctrl-A... [04:29] ddaa: cool. can you call me? (7270) === jd_ [n=jd@wikipedia/Meanos] has left #launchpad [] === niemeyer [n=niemeyer@201.14.57.43] has joined #launchpad === rpedro [n=rpedro@87-196-109-13.net.novis.pt] has joined #launchpad [04:50] bradb, do you have a copy of the no-RHS-portlets CSS somewhere? [04:50] kiko: if you mean scott's stuff, it's: [04:50] http://people.ubuntu.com/~scott/launchpad.user.css [04:50] and http://people.ubuntu.com/~scott/launchpad.user.js [04:56] bradb, Keybuk: hmmm. unfortunate that the RHS portlets get hidden -- can they be displayed under the LHS ones? [04:56] kiko: they don't get hidden [04:57] that's what the greasemonkey javascript is for [04:57] ah I see. [04:57] you can't do that in CSS alone? [04:57] no, you can't [04:57] not even if I modified the main template slightly? [04:57] in CSS alone, you can place column one and two above each other [04:57] but then the order is almost exactly the opposite to what's desired [04:58] how would you do that? [04:58] float the body on the right, and make the portlets floated on the left [04:58] they stack [04:58] but then you get "portlets, facets, more portlets, more facets" [04:58] when I wanted "portlets, facets" only === malcc [n=malcolm@host86-134-233-12.range86-134.btcentralplus.com] has joined #launchpad [04:59] hmm, can't seem to get it right. [05:00] of course, if you modified the LP css so everything just used the two column layout, that'd be *perfect* :p [05:00] I could modify the main template to make such customizations easier. [05:01] the basic problem is that the ordering of the template is such that it provides the order of the portlets and factets [05:01] it lists those down the LHS, then those down the RHS [05:01] with CSS alone, you can't reorder things === malcc [n=malcolm@host86-134-233-12.range86-134.btcentralplus.com] has joined #launchpad [05:05] kiko, by putting an extra div around all the LHS portlets but not the facets/menu? [05:05] maybe [05:06] (by golly this is a depressing conversation) [05:07] mpt: don't be depressed === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has left #launchpad [] === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [05:07] eventually, everybody will be using that greasemonkey stuff :) [05:08] I'm still not entirely happy with it though [05:08] the expanding portlets get in the way of ordinary mouse movement [05:09] mpt: did you have time to take a look at https://launchpad.canonical.com/SupportTrackerWorkflowSpec? [05:10] flacoste, I've been doing non-LP stuff the past couple of days [05:10] I'll have a Launchpad day today and look at it [05:10] kiko: it'd be really nice if every portlet and facet had an id, btw [05:10] mpt: ok, thanks! [05:10] (where by "today" I mean "after I wake up") [05:11] kiko: i agree with Keybuk, we could improve our HTML id/class tagging. It would make it easier to customize the layout using CSS/Javascript [05:12] flacoste: in general, i see that there is too much presentation markup in the HTML and not enough semantic markup === flacoste was accustomed to the well-designed Plone HTML/CSS [05:15] Well, we don't have any s [05:15] Most of our s don't mean anything in particular [05:16] Most of our s are inline headings, but CSS doesn't do inline headings so we'd still need the
s before them [05:17] I remove
s whenever I come across them, though some people like inserting them [05:17] mpt: what do you call inline headings? [05:17] and the Plone CSS was horrific. [05:18] flacoste, such as you might find in a dictionary [05:18] mpt: when was the last time you checked it? [05:18] mpt: something like what dt/dd is intended for? [05:18] yes [05:18] but you can't get that presentation with dt/dd either [05:18] (amusingly) [05:19] flacoste, iirc the copy we had was from April-ish 2005 [05:19] and when I nuked it circa October 2005, it dropped our CSS bandwidth by half [05:20] There's still remnants of it in launchpad.css, which I will remove one day [05:20] mpt: indeed the Plone CSS was big, they somewhat improved that with 2.1 though, but still it is big === SteveA [n=steve@88.118.141.60] has joined #launchpad [05:21] mpt: why not just use
for inline headings and adjust it in CSS to look right? [05:21] or