[12:22] <niemeyer> See you tomorrow guys!
[01:17] <lifeless> jamesh: ping
[01:27] <kiko> hey ho hey ho
[01:28] <kiko> lifeless, are you on adsl?
[01:37] <lifeless> yes
[01:42] <kiko> lifeless, what's the average latency to the first hop across your modem?
[01:47] <lifeless> mmm
[01:47] <lifeless> svcg isn't that useful
[01:47] <lifeless> it can be very small, and then blow out hugely
[02:11] <kiko> lifeless, I wanted to know the base latency -- mine is 200ms and I wanted to guage how bad/good it is
[02:20] <lifeless> thats terrible
[02:21] <bob2> I get 233ms to international sites
[02:47] <kiko> lifeless, is wireless latency (over, say, 1km) supposed to be better or worse than that?
[02:47] <kiko> we have the option of moving to wireless, which I'm entertaining as a way to get rid of telefonica
[03:18] <camilotelles> kiko: my latency here is 41 ms average
[03:25] <kiko> camilotelles, on adsl or wireless?
[03:25] <camilotelles> kiko: adsl
[03:25] <kiko> wow
[03:26] <camilotelles> kiko, are you sure that you are testing at the next hop?
[03:26] <kiko> unfortunately yes
[03:26] <camilotelles> the dslam interface?
[03:26] <kiko> the next pingable hop, anyway
[03:26] <camilotelles> how are the stats of your adsl? what is your modem?
[03:26] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Update fix-whitespace migration script (patch-2338<EMAIL_ADDRESS>[03:29] <camilotelles> kiko, try to see the stats of the ADSL link. maybe if you change your modem thinks can be better. I use a SpeedStream.
[03:29] <kiko> hmmm, maybe
[03:29] <kiko> ours is a dlink
[03:30] <camilotelles> kiko, look at the stats. everytime that i talk with telecom people, they congratulate me to use a speedstream modem.
[03:31] <camilotelles> kiko, recentely my telco line was terrible, i almost can't use the fone for talk, and the speedstream was rock solid.
[03:41] <kiko> interesting
[03:44] <jamesh> lifeless: pong
[03:46] <jamesh> kiko: WiMax is supposed to make wireless ISP service more feasible (compared to wifi)
[03:49] <kiko> jamesh, it's still a dream in these parts though
[03:57] <camilotelles> kiko: "The inherent delay in ADSL is due to the error correction techniques used to ensure that data traveling the 5km from your home to the exchange (and back) arrives intact. Simply, the more error correction that is added, the longer the delay, so a trade-off is used."
[03:59] <kiko> I wonder if wifi will be better
[03:59] <kiko> Max ms   	784.0 ms (78.4%)  	 	Average ms   	160.0 ms (16.0%)  	 	Current ms   	107.0 ms (10.7%)
[04:01] <camilotelles> kiko: i don't think why wifi can be better. I think that you have some problem with your line, modem or dslam.
[05:13] <lifeless> jamesh: was looking for the tests for the check-pending-reviews code
[05:14] <lifeless> jamesh: unless you object, I'm going to structure it to be a trivial import from a package, to facilitate testing
[05:24] <jamesh> lifeless: what you see in that module is all there is at the moment.  It was just a quick script to do the merges and diffs
[05:28] <lifeless> jamesh: so you are happy for me to go to town ?
[05:29] <jamesh> lifeless: sure.
[05:30] <lifeless> win 18
[05:34] <lifeless> jamesh: what package should I call it ?  pending_reviews ?
[05:35] <jamesh> lifeless: pendingreviews, probably.
[05:43] <kiko> SLEEPY
[05:54] <kiko> woooo!
[06:03] <lifeless> jamesh: you sure, isn't it convention to _ separate words ?
[06:03] <lifeless> I mean, I can do pendingreviews but it seems ugly
[06:04] <jamesh> lifeless: the majority of module and package names in launchpad are without underscores
[06:06] <lifeless> so this isn't in launchpad :), and Mark has ok'd it getting an open source release
[06:06] <lifeless> or something derived from it being open sourced
[06:07] <jamesh> okay.  Most things in the Python standard library don't use underscores either
[06:07] <lifeless> why not ? doesn't it make them hard to read ?
[06:07] <kiko> lifeless, can you review<EMAIL_ADDRESS>for us?
[06:08] <lifeless> sure thing
[06:08] <kiko> lifeless, would be a nice first review, and it's mixed C and python, which should be a good pick for you
[06:08] <kiko> not too big
[06:08] <kiko> gpgme is ev1l
[06:08] <jamesh> PEP-8: "Modules should have short, lowercase names, without underscores."
  I'm doing celso's other one, and will then move onto others
[06:09] <kiko> jamesh, I'm asking because I reviewed a fat-ass salgado patch and I don't want to do his second.
[06:09] <kiko><EMAIL_ADDRESS>[06:09] <kiko> if you can do that one, jamesh, I'm your fan
[06:09] <jamesh> kiko: okay.
[06:09] <kiko> it's big and would be a nice feature to land (but salgado needs to do magic to get it all in tomorrow..)
[06:10] <kiko> I need to do some serious staging testing though
[06:10] <kiko> jamesh, I'm going to do portlet mania and return path handling, though I'll ask stub to look at that as well
[06:10] <kiko> and then I'm going to bed
[06:11] <kiko> this leaves only the malone commandline interface
[06:11] <kiko> which steve can probably do
[06:11] <kiko> doh, reviews to the wrong list
[06:14] <lifeless> kiko: where should I mail the review to ?
[06:16] <kiko><EMAIL_ADDRESS>[06:21] <kiko> lifeless, my "doh" was related to my own mail
[06:23] <kiko> stub, can you help me by looking at<EMAIL_ADDRESS>after I do?
[06:25] <stub> Sure, but not for 2-3 hours (I have an appointment to sort Montreal flights)
[06:25] <kiko> stub, that's fine, it's only due in about 8h
[06:25] <kiko> (jamesh, I'm going to cheat by getting up late ;)
[06:26] <stub> Stick it in my queue when you are done so I don't forget
[06:26] <lifeless> jamesh: ok, boilerplate up:
[06:26] <lifeless> :!make check 2>&1| tee /tmp/v656798/11
[06:26] <lifeless> PYTHONPATH=/home/robertc/source/baz/pending-reviews--devel--0--patch-31/lib ./test_all.py
[06:26] <lifeless> test_main (pendingreviews.tests.test_pendingreviews.TestImports) ... ok
[06:26] <lifeless> ----------------------------------------------------------------------
[06:26] <lifeless> Ran 1 test in 0.002s
[06:31] <kiko-zzz> 5 reviews done
[06:31] <kiko-zzz> time for those famous zs
[06:31] <kiko-zzz> night
[06:34] <lifeless> jamesh: any reason you don't use pybaz ?
[06:35] <jamesh> lifeless: nope.
[06:35] <jamesh> lifeless: other than the fact that I was a lot more familiar with the command line API
[06:38] <lifeless> jamesh: can you pleae have a look at by pending-reviews--devel--0 branch, to see if you hate the stuff I've done
[06:38] <lifeless> jamesh: I'm now onto writing tests for baz namespace pickups etc, its more the infrastructure I dumped there I want to check
[06:39] <lifeless> its mirroring up now ...
[06:41] <lifeless> jamesh: done. just pull<EMAIL_ADDRESS>[06:50] <BjornT> jamesh: kiko told you to review salgado's basic voting branch, right? have you started yet?
[06:52] <kiko-zzz> jamesh, BjornT: I can do basicvoting tomorrow if you like
[06:52] <kiko-zzz> or hmm
[06:52] <BjornT> kiko-zzz: it was in my queue!
[06:53] <kiko-zzz> I know
[06:53] <kiko-zzz> I was about to steal it
[06:53] <BjornT> kiko-zzz: i have alread started, planned to finish it today
[06:53] <kiko-zzz> do you want it back?
[06:53] <kiko-zzz> ah, okay.
[06:53] <kiko-zzz> sure
[06:53] <kiko-zzz> let me give it back
[06:53] <BjornT> kiko-zzz: don't move things from other queues without asking. if i move it to my queue myself, it probably means i'm currently reviewing it
[06:54] <kiko-zzz> BjornT, don't be stingy, it's like 2am and I've been reviewing your patches. swedes!
[06:54] <BjornT> kiko-zzz: well i already spent one hour reviewing it...
[06:55] <kiko-zzz> that's okay, you can have it back, I'm not arguing
[06:55] <kiko-zzz> btw
[06:55] <kiko-zzz> BjornT, I stole portlet mania from you too
[06:55] <kiko-zzz> hopefully you'll appreciate that
[06:55] <kiko-zzz> I'll be asleep, anyway, though :)
[06:56] <BjornT> kiko-zzz: that's ok, i hadn't started to review it yet. you can have it if you want :)
[07:32] <lifeless> jamesh: ping
[08:34] <stub> Is james b still around or am I going to wake him up if I ping him?
[08:50] <jamesh> lifeless: looking at your changes: The parser.parse_args() call in pendingreviews.main() should probably use the argv list passed in
[08:50] <jamesh> lifeless: it seems like quite a bit of boilerplate unittest code
[08:55] <SteveA> hi
[08:58] <zyga> hello :)
[08:58] <zyga> hmm
[08:59] <zyga> language-selector is *still* not on the breezy package list
[08:59] <zyga> could someone try to find out why?
[09:02] <SteveA> stub: unlikely that jblack is around given the time, but possible
[09:15] <lifeless> jamesh: yes, the argv passed should be used, and if I make changes to the cli I'll do that, it was just part of the 'move to a library' step.
[09:16] <lifeless> jamesh: the test stuff - I don't have it in an installable importable package at the moment. I brought it in because it lets me do TDD really really easily.
[09:18] <lifeless> jamesh: I'm pushing some actual meat now.
[09:24] <lifeless> done
[09:52] <Sianis> hi all
[09:52] <Sianis> i have a little probleme
[09:52] <Sianis> i don't see the donload button, i can't download PO files
[09:54] <carlos> Sianis, URL?
[09:55] <carlos> hmmm
[09:55] <lifeless> jamesh: ping
[09:55] <jamesh> pong
[09:55] <lifeless> how do you test this at the moment ?
[09:55] <bob2> hm, vocabularies are a little confusing
[09:55] <carlos> the menu changes removed lots of links :-(
[09:55] <Sianis> https://launchpad.net/distros/ubuntu/breezy/+sources/partconf/+pots/pkgconf-partconf/hu/+translate
[09:55] <Sianis> example
[09:55] <lifeless> I've made a change that I couldn't see how to unit test in less time that writing the entire scrit
[09:55] <carlos> Sianis, you can use /+export instead of +translate
[09:56] <carlos> Sianis, or go to the template view and use the download link from there
[09:56] <Sianis> yes
[09:56] <Sianis> this is
[09:56] <Sianis> i know, so +upload
[09:56] <Sianis> but i try it +download!
[09:56] <Sianis> thanks !
[09:56] <carlos> Sianis, you are welcome
[09:56] <Sianis> thx
[09:56] <Sianis> :)
[09:57] <jamesh> lifeless: the tests I did were mostly manual
[09:57] <Sianis> Ubuntu leads the way, sir!
[09:57] <jamesh> lifeless: to test some of the output code, I added the --just-index arg to just update the index page, but that's about it
[09:57] <lifeless> mmm
[09:58] <lifeless> could you do me a favour then ? checkout my patch-12 on chinstrap and tell me if I've fucked it or not yet ? I've done the structural change I needed, now its down hill.
[10:00] <lifeless> oh, haven't mirrored for a bit :[
[10:00] <lifeless> una momento
[10:01] <SteveA> spiv: can i merge the enum-value branch once i've addressed the points you mention, or do you want to see the diff again before approving it?
[10:01] <sivang> Morning all
[10:01] <spiv> SteveA: Yep.
[10:01] <lifeless> jamesh: patch-9 is up, thats the latest
[10:01] <spiv> SteveA: Feel free to send me the diff anyway, if you like ;)
[10:01] <SteveA> ok
[10:02] <spiv> But I'm confident that it will be fine.  It doesn't exactly need major surgery ;)
[10:03] <lifeless> jamesh: what does PyErrorPrint() do ?
[10:04] <jamesh> lifeless: prints a stack trace
[10:04] <spiv> lifeless: file:///usr/share/doc/python2.4/html/api/exceptionHandling.html
[10:04] <lifeless> that seems quite intrusive
[10:05] <lifeless> is it not available from the gpgme_error object ?
[10:05] <lifeless> or is an error a sufficiently rare thing here that is ok to do that ?
[10:05] <jamesh> lifeless: there isn't a way for the callback passed to op_edit() to stop processing
[10:06] <jamesh> lifeless: so if the Python callback has some bugs in it, I either ignore the exception or print it
[10:06] <lifeless> would it be reasonable to collect them and give a list back ?
[10:07] <lifeless> I'll put my concerns in the review. thanks for the info - its what I needed
[10:07] <spiv> jamesh: Hmm, in hindsight, I should've asked in my review for you to add a comment about this to the code.
[10:08] <jamesh> lifeless: actually, it is possible that the returning an error value from edit_cb() would stop processing
[10:08] <jamesh> lifeless: there is essentially zero documentation for the interface
[10:09] <lifeless> I know
[10:09] <lifeless> it sucks
[10:09] <WaterSevenUb> zyga, you were saying something about gnome-weather, yesterday... ?
[10:10] <lifeless> so I'm not criticising the stop early or not, rather that its hard for users of the library to figure out that something is going wrong in their web server ;0
[10:10] <jamesh> lifeless: it's a problem that comes up with using C interfaces with callbacks from other languages
[10:10] <lifeless> some of the python changes look familiar ;0
[10:11] <jamesh> lifeless: if the callback was C++, what should you do if you get an exception there?
[10:11] <lifeless> so the call stack looks like:
[10:11] <zyga> WaterSevenUb: it contains many countries
[10:11] <lifeless> C++
[10:11] <lifeless> C++-binding
[10:11] <lifeless> C
[10:11] <lifeless> C-callback-thunk
[10:12] <zyga> carlos: language-selector is still not on the rosetta website
[10:12] <lifeless> (erm, reverse order, sorry)
[10:12] <WaterSevenUb> zyga, oh yeah.... so three different places:)
[10:12] <lifeless> and in C-callback-thunk we've recieved an exception we'd like to give to the outermost frame.
[10:12] <lifeless> assuming that the C layer allows early stopping ...
[10:12] <lifeless> the C++-binding frame has the opportunity to store its own state that the C-callback-thunk can reach.
[10:13] <jamesh> lifeless: sure.  If it does allow me stop, it would definitely be best to pass the exception up (which is pretty easy to do)
[10:13] <lifeless> in that state you stash the exception, return 'STOP-NOW' to the C layer, and then you can propogate the exception later.
[10:13] <WaterSevenUb> zyga, do you have gnome-weather available for translation?
[10:13] <jamesh> however, if the callback is going to be called repeatedly, it is less clear what to do
[10:13] <lifeless> if it doesn't allow you to stop then I'd have the callback-thunk stop calling the user code after an error is raise.
[10:13] <lifeless> *raised*
[10:13] <WaterSevenUb> zyga, do you know why in gnome the applets are translated in a common place and in breezy they are separated .. (it seems)?
[10:14] <lifeless> and once it stops being called, then we bubble back out and raise the first error
[10:14] <jamesh> lifeless: well, in this case, the function may not ever exit unless the callback does the right thing
[10:14] <lifeless> jamesh: I take it did that to you in testing
[10:14] <lifeless> ?
[10:14] <zyga> WaterSevenUb: no I have not check it yet... strange
[10:15] <zyga> WaterSevenUb: but IMHO that's better - they really should be separate packages
[10:15] <jamesh> lifeless: op_edit() is essentially just talking to "gpg --edit-key", and returns when the gpg exits
[10:15] <lifeless> jamesh: have you tried returning an error from the thunk ?
[10:16] <carlos> zyga, I see it... https://launchpad.net/distros/ubuntu/breezy/+sources/language-selector/+translations
[10:16] <lifeless> does it exit early ?
[10:16] <WaterSevenUb> carlos, and synaptic?
[10:16] <jamesh> lifeless: I didn't do much testing of the error cases, no.
[10:16] <lifeless> I think the increase in usability would be worth a test case for that.
[10:16] <carlos> WaterSevenUb, still missing
[10:16] <lifeless> its a pretty big win.
[10:16] <zyga> carlos: hmm
[10:17] <zyga> carlos: it was not there a moment ago
[10:17] <jamesh> lifeless: sure.  I've got some higher level testing of the code in my launchpad branch.
[10:17] <jamesh> lifeless: I guess I'll look at doing adding some to pyme directly then
[10:17] <carlos> zyga, I didn't change anything :-P
[10:18] <WaterSevenUb> zyga, sometimes is hard to find packages ;)
[10:18] <zyga> carlos: okay - the important thing is that it works
[10:18] <carlos> zyga, if you used the sourcepackage search form... is normal that you didn't find it
[10:18] <zyga> I was looking here: https://launchpad.net/distros/ubuntu/breezy/+lang/pl
[10:19] <carlos> zyga, we need to import the published information into launchpad to have that search form working
[10:19] <carlos> zyga, oh, that url only shows the packages that have any translation
[10:19] <Kinnison> carlos: FYI, once jamesh has got the GPG stuff done, we're fairly much ready to import breezy
[10:19] <zyga> carlos: are you sure? I've found gcc-4.0 there two days ago and submitted my 25% translation
[10:20] <carlos> Kinnison, cool
[10:20] <zyga> (it had no translation at all before that)
[10:20] <Kinnison> stub: ping?
[10:20] <stub> yo
[10:20] <carlos> zyga, because at least, one string was translated
[10:21] <zyga> there should be
This webpage does not contain packages without any translation

[10:26] <lifeless> jamesh: ok, review sent.
[10:26] <lifeless> please let me know if I've f*cked pending-reviews already.
[10:26] <lifeless> I'll finish the work on the plane I think.
[10:26] <lifeless> night all
[10:35] <zyga> carlos: ping
[10:35] <zyga> carlos: there is clearly a bug here: https://launchpad.net/distros/ubuntu/breezy/+lang/pl
[10:35] <zyga> carlos: Below, you can see all of the registered translation templates in Ubuntu 5.10. Choose a template name to begin translating.
[10:35] <zyga> carlos: you said that it only shows partially translated packages
[10:36] <zyga> carlos: yet, check 'wesnoth' - no translations at all
[10:36] <carlos> zyga, but there are other potemplates that have a translation
[10:36] <carlos> so we show all
[10:37] <zyga> carlos: and abiword?
[10:37] <zyga> carlos: not one translation, not one other package
[10:38] <carlos> hmmm
[10:38] <carlos> not sure...
[10:38] <zyga> I really dont get this - why doesn't it simply show *all* pot's
[10:38] <zyga> wait a minute!
[10:38] <carlos> I need to review that page anyway as most of the 'deprecated' entries should not appear
[10:38] <carlos> that's why they are deprecated :-)
[10:39] <jordi> carlos: what about the review-breezy-foo templates? Are those showing up still?
[10:39] <zyga> https://launchpad.net/distros/ubuntu/breezy/+lang/eu_ES
[10:39] <zyga> check this out - it has very little translation
[10:40] <zyga> how are those packages selected, it seems random to me?
[10:40] <zyga> jordi: yes they do
[10:40] <carlos> jordi, they need manual review, if you are bored and want to help to fix them... we should fix all those before breezy release
[10:40] <jordi> zyga: eu_ES should be eu only
[10:40] <jordi> carlos: manual review in what sense?
[10:40] <carlos> jordi, and change the import approach to prevent that for breezy+1
[10:41] <Kinnison> stub: any idea what's happening with salgado's patch? I really want to get my stuff merged but it'll potentially make it harder to cherrypick anything touching packages
[10:41] <carlos> jordi, check the real translation domain, fix that and if it already exists, hide the duplicates
[10:41] <stub> Which patch? The shipit one?
[10:42] <jordi> yuck, that sucks
[10:42] <zyga> BTW: what are those -review templates?
[10:42] <carlos> zyga, could be, I don't know the details of those pages as I didn't develop it, I need to look at it closer. Please, file a bug
[10:42] <stub> Last I heard it was undergoing Kiko's review. DB patch is approved.
[10:42] <zyga> carlos: k
[10:42] <Kinnison> Right
[10:42] <Kinnison> stub: and once it's merged you'll use that as your tag point for the next production cycle?
[10:42] <carlos> zyga, automatic imports that need manual review post importing from Ubuntu
[10:42] <stub> Kinnison: Yes, unless other bugfixes land soon after.
[10:42] <Kinnison> okay
[10:47] <zyga> carlos: filed, #2036
[10:47] <cprov> morning hackers
[10:47] <carlos> zyga, thanks
[10:47] <carlos> cprov, good morning
[10:49] <zyga> eh, more ill-tagged po files, https://launchpad.net/distros/ubuntu/breezy/+sources/kcheckgmail/+pots/kcheckgmail/pl/+translate
[10:50] <carlos> ill-tagged?
[10:50] <vinsci> hi carlos - any news on the code release permission?
[10:51] <carlos> vinsci, hadn't time yet :-(
[10:51] <zyga> carlos: latin2 posing as utf8 or vice-versa
[10:51] <carlos> right
[10:51] <carlos> zyga, I see it now
[10:52] <zyga> carlos: this time is something different :)
[10:52] <carlos> zyga, did you detect who is doing that?
[10:52] <zyga> carlos: probably clueless translators
[10:52] <zyga> carlos: this seems like a windows encoding - let me check
[10:53] <vinsci> carlos, well, I can't contribute without code...
[10:53] <carlos> vinsci, I know :-( I suck
[10:53] <carlos> It's just that language packs are driving me crazy
[10:54] <SteveA> stub, lifeless, bradb-away, kiko-zzz: just been talking with BjornT around a whiteboard about brad's IBugInContext proposal.  I think we have now clearly worked out what the core issue is, and two strategies for addressing it.
[10:54] <SteveA> one strategy is IBugInContext (which should really be called IBugWithContext)
[10:54] <stub> I BuggedContext? IBuggyContext? IBuggeredContext?
[10:54] <zyga> carlos: that is not any encoding used in poland - I'll check some ancient ones... ehh
[10:55] <SteveA> another strategy is to use self.context = IBug(context) in views / pages / portlets where you want it to work with both IBugTask and IBug
[10:55] <SteveA> BjornT is writing this up at the end of brad's proposal.
[10:55] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Added also the download link for POFiles (patch-2339<EMAIL_ADDRESS>[10:55] <SteveA> stub: you aussies are obsessed with buggery.
[10:55] <stub> Mmm.... buggery....
[10:56] <SteveA> http://sinfest.net/comics/sf20050901.gif
[10:57] <SteveA> actually, http://sinfest.net/comics/sf20050830.gif  this one is very aussie-inspired ;-)
[10:58] <vinsci> SteveA, how about a baz link to the published parts of launchpad? :)
[11:00] <zyga> ehhh - that file is totally fsck'd up... I don't know any encoding that needs 5 bytes to store near-ascii character
[11:01] <zyga> carlos: what does rosetta do when there is an error in re-encoding files to/from utf8?
[11:01] <carlos> zyga, it rejects the import
[11:01] <carlos> or it should at least...
[11:02] <zyga> carlos: I guess it didn't before - I'll try to test this later on
[11:02] <zyga> carlos: I'll write a script that de-fcsk that file
[11:03] <carlos> ok
[11:03] <carlos> zyga, thanks
[11:28] <carlos> stub, hi, how is going the script on staging?
[11:28] <zyga> carlos: done - I'll ask pitti to upload the patch
[11:28] <WaterSevenUb> carlos, PT translators are trying to organize a long-run session to check translation problems. 6th October a langpack will be released, correct? Some guy you pointed me the other day said that after that small updates would be possible.
[11:28] <carlos> zyga, ok
[11:29] <stub> carlos: I thought I emailed you?  Script completed the first section and died. I made a fix and ran the rest. Changes were committed to rocketfuel.
[11:29] <carlos> WaterSevenUb, every month, we will release language package updates
[11:29] <carlos> WaterSevenUb, until the end of life of the release
[11:29] <carlos> oh
[11:29] <carlos> stub, no, I didn't get that email
[11:30] <carlos> stub, what was the problem?
[11:30] <stub> Ahh.. the window is still here waiting for me to his send from this morning ;)
[11:30] <carlos> :-P
[11:30] <carlos> if the first section is done, that's enough, the second part of the script is only some cleanup unrelated with language packs
[11:31] <carlos> so I can generate a new language pack now :-)
[11:31] <stub> I think the code that updates references to empty translations was finding the empty translation that was going to be deleted, effectively doing a noop and causing the delete to fail.
[11:32] <WaterSevenUb> carlos,yeah.. but we are worried with installs with no network... I mean, a good support in our language should ship with the ISO's. THe majority of net access in here is via ADSL speedtouch which is not easily configurable. So... my point is that in the end, people will live without updates, mom, grandma, etc. will live with openoffice, make some documents, browse the distribution...
[11:33] <WaterSevenUb> carlos, the langpacks are shipped with the ISO's?:)
[11:33] <carlos> WaterSevenUb, not all languages are
[11:33] <WaterSevenUb> carlos, now I remember to see something like " for full support you need net...." during install.
[11:33] <carlos> WaterSevenUb, you will need to ask pitti for that info
[11:33] <WaterSevenUb> carlos, ok
[11:33] <carlos> stub, oh!
[11:34] <carlos> hmm
[11:34] <carlos> I don't understand it
[11:34] <carlos> I added some code to prevent that error to happen
[11:35] <carlos> stub, I know that the new constraint would kill the script, and that's why I tried to fix that, What did I miss?
[11:36] <stub> a where clause - don't say 'give me all the possible matches', say 'give me all the posibilities except for the one I'm about to delete'
[11:36] <stub> Trivial fix once I realized
[11:36] <stub> But easy one to miss
[11:37] <stub> Or maybe it was the commit I added too - check the diff anyway
[11:37] <stub><EMAIL_ADDRESS>[11:38] <carlos> ok
[11:39] <carlos> stub, thanks
[12:15] <zyga> carlos: is there any page that shows uploaded .po status?
[12:15] <zyga> carlos: like 'pending' or 'broken'?
[12:15] <carlos> not yet
[12:15] <zyga> carlos: I'm not sure what to do - uploads just dissappear
[12:16] <carlos> zyga, I fixed that, should appear again soon
[12:16] <carlos> zyga, just use something like pl/+upload
[12:16] <zyga> carlos: no no
[12:17] <zyga> carlos: I'm talking about '1) upload .po say..  3 po files, 2) wait 3) recieve confirmation about one of them 4) what about the other two?
[12:17] <carlos> zyga, oh!
[12:17] <carlos> ok, zyga increase the review date of the .po file
[12:17] <carlos> the import is being rejected because it's the same date
[12:18] <zyga> carlos: d'oh... editing with vim has one disadvantage :)
[12:18] <carlos> zyga, ;-)
[12:18] <carlos> anyway, file also a bug, we should send you an email so you know the error
[12:18] <zyga> carlos: small part of log files sent via email to explain this would be great here ;)
[12:18] <zyga> carlos: k
[12:19] <carlos> zyga, we do that, but not for all errors
[12:21] <zyga> done, 2038
[12:26] <carlos> zyga, thanks
[12:26] <carlos> (again)
[12:27] <carlos> :-P
[12:27] <zyga> carlos: :-)
[01:28] <Kinnison> stub: do you happen to know what branch salgado is wanting merged?
[01:28] <Kinnison> stub: so I can check if it'll conflict with my stuff
[01:31] <stub> Kinnison: https://chinstrap.warthogs.hbd.com/~salgado/launchpad--shipitng--0.diff is what I saw go past
[01:31] <stub> Should all be mirrored in his archive on chinstrap since it was being reviewed
[01:37] <Kinnison> ta
[01:49] <WaterSevenUb> zyga, you expert in translation findings ... :) During breezy installation "Time zone configuration" was not translated. any idea where it is?
[02:53] <azazel> hi all! do you know if there is a way to upload an entire .po into rosetta? yesterday i was unable to find it? any hint?
[02:53] <Kinnison> gah!
[02:53] <Kinnison> salgado: Either you manage to get your branch merged v. soon, or I'll merge mine and you'll be stuck with conflicts which will stop you going into production this week :-(
[02:53] <Kinnison> salgado: I'm getting very desperate to merge
[02:57] <salgado> Kinnison, would you really do that with me?
[02:58] <Kinnison> salgado: I have cprov here for one more week, we need to get lots done and a large amount of it is blocked on this merge
[02:58] <carlos> azazel, just add +upload to the end of the URL, for instance: https://launchpad.net/distros/ubuntu/breezy/+sources/glib2.0/+pots/glib20/sq/+upload
[02:58] <Kinnison> salgado: but this merge really shouldn't go live without a week of people testing their apps
[02:59] <Kinnison> salgado: the only conflict you have with my branch is in security.cfg
[02:59] <Kinnison> If you can alter your branch not to conflict with mine then you might stand a chance of being cherrypicked if I merge first
[02:59] <carlos> azazel, the link is missing, the page is there, it will reappear soon. Sorry for the problems it's causing to you.
[02:59] <jordi> azazel: this is a temporary measure, there will be a link in a few days
[02:59] <Kinnison> but I'm really reaching the limit of how long I can hold off
[02:59] <Kinnison> I've wanted this merged since wednesday night
[03:00] <salgado> okay, don't worry about my merge. I see what I can do later
[03:00] <azazel> carlos, jordi thanks, np:) the important thing is that i don't have to do my translations ttw:)
[03:00] <jordi> right :)
[03:01] <azazel> but that i can use emacs:)
[03:01] <Kinnison> salgado: Are you sure? I thought you were aiming to merge this morning (your time)
[03:01] <azazel> to download is the same thing? i append a +download?
[03:02] <salgado> I don't want to block you. it's my fault that it's not merged yet. I'll deal with any problems
[03:02] <bradb> morning
[03:02] <Kinnison> okay
[03:04] <azazel> no, however, i have the .po in the sources
[03:07] <SteveA> bradb: ping
[03:07] <SteveA> kiko-zzz: still asleep?
[03:11] <bradb> SteveA: hi
[03:12] <carlos> azazel, +export
[03:13] <SteveA> bradb: i worked with bjorn on the BiC stuff.  i also talked with mark about it in a phone call where we talked about various malone directions.
[03:13] <mpt> carlos: Why do we have +upload and +export, rather than +upload and +download, or +import and +export?
[03:13] <bradb> SteveA: Cool. What came out of it?
[03:14] <SteveA> bradb: there's a draft of a different way to do it at the bottom of the spec you wrote.  i need to review it with bjorn still.  basically, we're not going to do BiC, but instead handle it by using  self.context = IBug(context) in the __init__ of view classes where needed
[03:14] <carlos> mpt, because we got those urls first... feel free to change them :-)
[03:14] <carlos> mpt, btw... with the menu removals, we those links in Rosetta...
[03:15] <carlos> s/we those/we lose those/
[03:15] <mpt> What menu removals?
[03:15] <mpt> sabdfl *moved* the application menu from tabs to a portlet
[03:16] <mpt> It was just a change in presentation
[03:18] <azazel> mpt, feel free to change them, but keep me in touch:)
[03:18] <bradb> SteveA: Have a few things to do first here (small email bits, and get a merge request submitted to pqm), but will take a careful read of BiC in about 30 mins to an hour
[03:18] <SteveA> ok
[03:20] <carlos> mpt, the upload / download links just disappear from Rosetta
[03:20] <carlos> I had to add them again
[03:21] <mpt> carlos: I saw that, I'm just asking what "menu removals" you're talking about
[03:21] <mpt> i.e. how did that bug happen?
[03:21] <carlos> mpt, we had some menu tabs with those actions
[03:22] <carlos> that were removed with this week production update
[03:22] <mpt> Yes, that's what I'm asking about
[03:22] <mpt> Do you know how it happened?
[03:22] <carlos> mpt, those actions were removed but were not restored inside the actions portlet
[03:22] <carlos> mpt, wasn't that a planed feature?, remove those tab actions
[03:22] <mpt> Who removed them?
[03:23] <carlos> I thought you removed the tab actions
[03:24] <mpt> No
[03:24] <mpt> As I said, Mark moved the application menus (i.e. the tabs, wherever they appear) to their own portlet.
[03:25] <mpt> So if any items actually *disappeared*, it was for some other reason.
[03:25] <carlos> then he forgot rosetta's one...
[03:25] <mpt> carlos, it was a change to the main template
[03:25] <mpt> it applies to every page in Launchpad
[03:25] <mpt> The main template doesn't care what you put in the menus, it just presents them in a particular way
[03:25] <bradb> mpt: Do you see there being many user-visible changes left to do for Malone menus?
[03:26] <mpt> carlos: So if any items disappeared, it was for some other reason.
[03:26] <mpt> And it would be nice to avoid such regressions in future, which is why I'm interested
[03:26] <carlos> mpt, not any, but all those actions are missing
[03:26] <carlos> mpt, the only actions that are still there are the ones that you leave behind insid ethe actions portlet
[03:26] <carlos> mpt: https://launchpad.net/products/wordpress/+series/1.5/+pots/wordpress-1.5/es
[03:26] <carlos> look at it
[03:27] <carlos> it's exactly the same we had except the missing menu
[03:27] <carlos> no edit, no upload, no download....
[03:27] <carlos> those actions were already there before
[03:27] <carlos> so the main template change is not working here
[03:28] <mpt> hmmm, ok, maybe it was Mark then
[03:28] <mpt> because he told me what changes to make
[03:28] <niemeyer> Do I need a specific version of plpython to run launchpad?
[03:28] <niemeyer> 7.4 and 8.0 are available on breezy
[03:28] <mpt> carlos: and when I'd finished them, the upload/download etc were at the top of the right column
[03:28] <carlos> niemeyer, I think 7.4
[03:28] <mpt> with little plone (>) icons
[03:29] <carlos> mpt, hmmm, yeah, I remember that from staging....
[03:29] <carlos> mpt, but something is failing on production
[03:31] <carlos> see you later
[03:32] <niemeyer> carlos: THanks
[03:40] <Kinnison> does it have any products in it?
[03:40] <Kinnison> Do you want me to upgrade the dogfood install?
[03:46] <mpt> Kinnison: Yes, it does have products in it, and no, I don't use dogfood for anything
[03:47] <mpt> Kinnison: Try following any of the links in https://dogfood.ubuntu.com/products/+all
[03:50] <Kinnison> it's a bizarre database issue
[03:50] <Kinnison>     *
[03:50] <Kinnison>       AttributeError: 'DistroRelease' object has no attribute 'datecreated'
[03:50] <Kinnison> Not sure what to do really
[03:57] <niemeyer> SteveA: There are two entries mentioned in the launchpad wiki that I couldn't find:
[03:57] <niemeyer> #
[03:57] <niemeyer> set up the database following the Launchpad wiki database setup instructions
[03:57] <niemeyer> #
[03:57] <niemeyer> check out the current versions of Launchpad following the instructions in the Launchpad wiki.
[03:58] <niemeyer> The Launchpad/Database page seems to be missing
[03:58] <niemeyer> And I could't find the page described in the second line
[03:58] <niemeyer> (with checkout instructions)
[03:58] <SteveA> what page do i need to look at to see what you see?
[03:58] <niemeyer> Links would be nice, btw. :)
[03:58] <niemeyer>  /Launchpad/DevelopmentEnvironment
[03:59] <niemeyer> Mini-setup Guide
[03:59] <SteveA> where is that?
[03:59] <niemeyer> In the wiki (was that the question)?
[03:59] <SteveA> give me the full url
[03:59] <niemeyer> https://wiki.canonical.com/Launchpad_2fDevelopmentEnvironment
[03:59] <SteveA> launchpad stuff is generally on wiki.launchpad.canonical.com
[04:00] <SteveA> stuff on wiki.canonical.com is likely to be obsolete
[04:00] <niemeyer> Ahh.. that explains it
[04:00] <SteveA> and should probably be removed or have a pointer to an equivalent place in the launchpad wiki
[04:02] <niemeyer> Are you aware about any equivalent pages in that wiki, with a development startup guide?
[04:02] <niemeyer> Found it!
[04:02] <niemeyer> RocketFuelSetup
[04:14] <bradb> mpt: Is "Bug #42 - Add an Attachment" the right way to style that kind of title? If not, what is the right way?
[04:22] <dilys> Merge to<EMAIL_ADDRESS>Publishing database rework. Renames BinaryPackage and the publishing tables. Likely to cause fallout not caught in tests yet. r=stevea,stub (patch-2340<EMAIL_ADDRESS><EMAIL_ADDRESS>[04:22] <Kinnison> woohoo
[04:28] <niemeyer> Kinnison: What's the merge procedure?
[04:28] <niemeyer> Kinnison: Is there a place where you request such merges?
[04:29] <niemeyer> Humm..
[04:33] <Kinnison> PQM takes a little while to get used to, and then you start to love it (except when you hate its guts, which will be most of the time)
[04:34] <mpt> bradb: "Attach file to bug #42" would work
[04:35] <bradb> mpt: even though all the other bug and task pages start with "Bug #N - ..."?
[04:35] <bradb> er, actually "Bug #N ..."
[04:36] <mpt> They do?
[04:36] <mpt> Well, as long as this is all in pagetitles.py, I can fix it later
[04:36] <Kinnison> I will now update dogfood with the latest rocketfuel
[04:36] <bradb> mpt: they do, as per what you and I agreed on
[04:37] <bradb> e.g. the bug page title is "Bug #42 - The Bug Title", and the task page title is "Bug #42 in The Context - The Bug Title"
[04:37] <mpt> bradb: Eh, well if you already know the right way to style them, don't invite me to disagree with my previous self ;-)
[04:39] <Kinnison> mpt: How long until you're done with buildui ?
[04:39] <niemeyer> Kinnison: Quite interesting system indeed
[04:42] <bradb> mpt: https://launchpad.net/malone/bugs/1266 was the bug we discussed about that
[04:43] <mpt> Kinnison: I should have something you can merge from in the next hour
[04:43] <mpt> Kinnison: but there's quite a bit of work for cprov still to do
[04:43] <mpt> linking things
[04:43] <mpt> in particular
[04:43] <Kinnison> but we needto get these things cycling as fast as we can
[04:44] <mpt> And the URLs don't match the spec, which might be reasonable, but if so it should be reflected in the spec
[04:44] <mpt> and then there's the "Not yet !!!!!!!"
[04:45] <cprov> mpt: Kinnison is suggesting to do preliminar review on that code, it can be merged yet, I know
[04:45] <Kinnison> s/can/can't/
[04:45] <Kinnison> :-)
[04:48] <mpt> cprov: Have you merged rocketfuel into your branch in the past few days?
[04:52] <cprov> mpt: 30/08
[04:52] <Kinnison> tuestag
[04:52] <Kinnison> carlos: what's this rosetta language thing running on dogfood?
[04:54] <carlos> Kinnison, language pack export
[04:54] <Kinnison> oh, umm hehe
[04:54] <Kinnison> dogfood is mid-update right now
[04:54] <carlos> Kinnison, don't worry, I'm using staging's db
[04:54] <Kinnison> okay
[05:00] <kiko> hey ho hey ho
[05:01] <bradb> SteveA: I'm looking at BiC now, btw
[05:03] <kiko> bradb, got your review?
[05:04] <bradb> kiko: yes, thanks; it's all in pqm's hands now
[05:05] <kiko> great
[05:05] <kiko> it was actually pretty small
[05:07] <SteveA> bradb: great.  please talk with BjornT about it.
[05:07] <bradb> small is the new big
[05:08] <bradb> SteveA: will do, thanks
[05:15] <Kinnison> dogfood is running again
[05:15] <Kinnison> there are lots of broken pages
[05:15] <Kinnison> many related to rosetta
[05:15] <Kinnison> E.g. https://dogfood.ubuntu.com/ appears to be rosetta related
[05:18] <kiko> Kinnison, running tip?
[05:18] <bradb> BjornT: around?
[05:19] <carlos> Kinnison, :-?
[05:19] <BjornT> bradb: yeah
[05:19] <carlos> Kinnison, again?
[05:20] <bradb> BjornT: hi, do you have time to discuss BiC now then?
[05:20] <carlos> Kinnison, that error is because you don't have latest code from rocketfuel....
[05:20] <carlos> Kinnison, don't ask me how is that possible
[05:20] <BjornT> bradb: sure
[05:20] <carlos> but rocketfuel has that 'ubuntu_translationrelease' defined
[05:20] <dilys> Merge to<EMAIL_ADDRESS>[r=kiko]  portlet mania, the finale. add sane titles, portlets and redirect-to-bug-page-after-processing to edit pages linked from the bug page (patch-2341<EMAIL_ADDRESS>[05:20] <carlos> Kinnison, did you tried to get a fresh checkout?
[05:21] <bradb> BjornT: ok, here's what i noted from reading your additions
[05:21] <kiko> congrats bradb
[05:21] <bradb> 1. the URL list is missing URL list is missing $bugpage/foos/+new
[05:21] <bradb> kiko: thanks :)
[05:21] <bradb> 2. /products/firefox/+bug/23/foo/42/+edit should probably be /products/firefox/+bug/23/foos/42/+edit
[05:21] <bradb> 3. "Note, for the last URL, the context will be an ICVERef"? The context could be a number of different things for that URL.
[05:22] <bradb> and, lastly:
[05:22] <bradb> 4. so +edit, +secrecy, and the other pages that edit (or add) bug-specific things will be registered on IBugTask? will a maintainer expect to find bug-editing pages in bugtask.zcml?
[05:22] <bradb> BjornT: In what order do you want to address those points?
[05:22] <Kinnison> carlos: completely fresh checkout afaict
[05:22] <Kinnison> carlos: I'll blow away the revision library and start again
[05:23] <carlos> Kinnison, yes, please
[05:23] <BjornT> bradb: let's start with 1.
[05:23] <bradb> :)
[05:23] <carlos> Kinnison, anyway I will check it again....
[05:23] <bradb> BjornT: so, is there any specific reason why that URL wasn't mentioned?
[05:23] <BjornT> bradb: i thought the plan was to have +newfoo instead of foos/+new. or am i mistaken?
[05:24] <bradb> i.e. did mark say to mandate +addfoo? (i'd be ok with that, but either way, the current URL scheme was left out)
[05:24] <Kinnison> carlos: thanks
[05:24] <carlos> Kinnison, I'm checking it on mawson without using any revision library
[05:24] <carlos> np
[05:24] <Kinnison> Right, I'm blowing away the revlib for the launchpad user before trying again
[05:24] <Kinnison> kaboom!
[05:24] <Kinnison> :-)
[05:25] <bradb> BjornT: i'm not aware of a place where that's been formalized and written down, so I can't say for sure. until then, it seems to me that the current URL that's in production deserves at least some kind of mention, even if to say that it's going to move to +addfoo.
[05:25] <bradb> BjornT: do you remember a specific conversation where the sab said we'd go with that
[05:25] <bradb> ?
[05:26] <bradb> BjornT: if we are mandating that, it seems to me that we should mandate +editfoo/... as well
[05:27] <BjornT> bradb: no can't remember. personally i like it, though, since there's easy access to the context. but i can add foos/+new as an example as well.
[05:28] <carlos> Kinnison, that method is still there with<EMAIL_ADDRESS>[05:28] <bradb> kiko: what do you think. should we keep $bugpage/foos/+new and $bugpage/foos/.../+edit, or should we mandate +addfoo and +editfoo?
[05:29] <BjornT> bradb: +addfoo doesn't imply +editfoo. compare how it will work with bugs (+bug/42/+edit, bug not +bug/+new)
[05:30] <kiko> hmmm?
[05:30] <Kinnison> carlos: getting fresh checkout with no revlib
[05:31] <SteveA> bradb: it is .../+bug/23/+edit, and .../+addbug (or something like 'addbug')
[05:31] <bradb> +filebug, yeah
[05:31] <SteveA> we're not going to do +bug/23/+new
[05:32] <SteveA> or +bug/+new
[05:32] <bradb> right, that much is clear
[05:32] <SteveA> or +bugs/+new
[05:33] <bradb> right, that's noted by a rejected bug report #1366
[05:34] <bradb> maybe +addcve and $bugpage/+cve/...?
[05:34] <carlos> Kinnison, ok
[05:34] <SteveA>  +cve is going away anyway, i expect
[05:35] <SteveA> cve data will become top level content objects in thier own right
[05:35] <SteveA> and bugs will refer to cve objects
[05:35] <kiko> right
[05:35] <kiko> that's the plan
[05:37] <bradb> makes sense
[05:37] <bradb> SteveA: but what about the URLs to traverse to those things within the context of a specific bug?
[05:38] <bradb> and, well, to add those things within the context of a specific bug, etc.
[05:48] <bradb> BjornT: so, while that's churning, #2 kind of depends on the answer to that too. so perhaps we should move to #3.
[05:48] <bradb> #3 is basically just an issue of accuracy. i understood what you meant.
[05:49] <BjornT> bradb: yeah, i used cve as an example first. then i got told that cve:s will be top level objects, and forgot to change it.
[05:51] <bradb> ok, maybe #3 slightly depends on #1 and #2 too (and i'm not yet sure that not having context-sensitive cve/watch/attachment, etc. is a good idea), so maybe we should jump to #4
[05:52] <bradb> BjornT: so, if i were going to pay you a large sum of money to guess in which ZCML file you would find registered the $bugpage/+edit page to edit the bug description, which ZCML file would you guess that to be in?
[05:52] <bradb> same goes for +secrecy, +duplicate, and all the other bug-specific pages
[05:53] <BjornT> bradb: so, 4. is a good question. although both solutions have that problem, +editstatus would be registered on a bug, but would edit a bugtask.
[05:54] <bradb> BjornT: it wouldn't be registered on a bug
[05:54] <bradb> it would be registered on a bug with context
[05:54] <bradb> +editstatus is "editing the status of the bug in that context"
[05:54] <BjornT> bradb: so you could see it this way, everything that deals with a bug will be registered on the same interface
[05:55] <BjornT> bradb: but you're still editing the bugtask
[05:56] <bradb> BjornT: either way, i think there's confusion. i think that one option produces a much greater amount of confusion than the other though.
[05:56] <SteveA> bradb: we're not going to do BiC
[05:56] <bradb> ok
[05:56] <bradb> what is the point of dicussing BiC then? :)
[05:57] <bradb> er, i guess you meant IBugInContext
[05:57] <SteveA> the point is to discuss the details of the solution to the issue that bjorn and i came up with, and that mark approves of.
[05:59] <bradb> BjornT: ok. as i understand it then, all the bug-specific editing pages will be registered on IBugTask, using the schema="...IBug", and we'll write an adapter from IBugTask to IBug, right?
[06:00] <BjornT> bradb: yeah, exactly
[06:01] <bradb> BjornT: ok, and what's the decision on the bug-related object add/edit pages? will those become top-level objects that can't be traversed anymore in the context of a particular bug?
[06:02] <Kinnison> Well, I've got my completely fresh checkout done
[06:02] <Kinnison> and I still get irritating errors on the front page
[06:02] <Kinnison> any more clues?
[06:03] <SteveA> BjornT: that's interesting.  i thought you'd just use the context = IBug(context) thing instead of using schema="...IBug", but i guess it ends up the same.
[06:04] <BjornT> SteveA, bradb: well, to be clear. the schema for the edit pages will stay the same
[06:04] <bradb> yep
[06:07] <bradb> BjornT: ...and as for the bug-related object add/edit pages?
[06:11] <BjornT> bradb: well the edit and index pages will stay the same. the add pages i'm not quite sure what the final verdict is.
[06:11] <bradb> BjornT: IOW, you will be for sure able to edit a CVE ref somewhere under a bug page URL?
[06:13] <BjornT> bradb: the cve will move to top level objects. i'm not sure exactly how that will be handled, let's care about that later. but for other bug objects, i'm quite sure
[06:13] <kiko-fud> carlos, there are items in the faq on macros, and you can look at bugtarget-macros-tableview or so
[06:13] <carlos> kiko-fud, don't worry, I found what I needed already, thanks
[06:14] <kiko-fud> sure
[06:14] <kiko-fud> mail me a diff before committing, I'd like to see how it turned out, but you don't need to wait for my approval
[06:15] <bradb> BjornT: i.e. you're sure that you can edit an ext ref, subscription, watch, and attachment somewhere a bug URL still, right? this matters to the extent that i need to know this so that I know what tests have to pass for the new URL scheme to be considered functional
[06:18] <carlos> kiko-fud, ok
[06:18] <BjornT> bradb: i haven't heard anything indicating that you shouln't (except that mark would redo subscriptions). i also can't see a reason why you shouldn't be able to do it.
[06:18] <bradb> ok
[06:19] <bradb> BjornT: so, are there any changes required to the existing bug-related object edit URLs or can they remain as is?
[06:20] <bradb> (and, well, the existing bug-related object add URLs, for that matter.)
[06:20] <kiko-fud> SteveA, right -- that was my concern as well (can't msg you without friggin changing my nick and I need fud)
[06:21] <kiko-fud> SteveA, btw, spiv already looked at the patch I had asked you to, so...
[06:21] <SteveA> kiko-fud: it says on the freenode website how to register other related nicks
[06:21] <SteveA> spiv's a review machine
[06:22] <kiko-fud> SteveA, I'll do it, I just suck
[06:22] <kiko-fud> SteveA, you could reciprocate by looking at two of his
[06:22] <SteveA> sure, just say which
[06:23] <kiko-fud><EMAIL_ADDRESS>[06:23] <kiko-fud><EMAIL_ADDRESS>[06:23] <kiko-fud> SteveA, both are very small
[06:24] <kiko-fud> SteveA, doh, doh, doh, use /filtered-diff instead of merge, sorry
[06:24] <SteveA> kiko-fud: okay.
[06:24] <kiko-fud> SteveA, there's also<EMAIL_ADDRESS>[06:25] <kiko-fud> SteveA, all under 400 lines
[06:25] <SteveA> k
[06:25] <kiko-fud> niemeyer,  porque no gosto de ti :)
[06:25] <kiko-fud> niemeyer, vou comer, te ligo  tarde
[06:25] <kiko-fud> lol
[06:26] <bradb> BjornT: ping
[06:26] <BjornT> bradb: i think the bug-related-object urls can stay as they are for now. it's trivial to change them later.
[06:26] <bradb> ok
[06:26] <BjornT> it's better to do one change at a time
[06:27] <carlos> will be back in an hour or so
[06:27] <bradb> after all this kaffuffle, and we end up *precisely* at the very first solution I had already about 80% implemented. :P
[06:29] <bradb> BjornT: can i leave it to you to update the spec while i unwrite some code here?
[06:30] <BjornT> bradb: yeah, sure
[06:31] <bradb> thanks
[06:39] <bradb> SteveA: do you have about 5 mins to discuss BugRelatedObjectAddView and BugRelatedObjectEditView?
[06:40] <bradb> kiko suggested that I ask you about it
[06:48] <bradb> right, i'm heading out for lunch now, but i'll try again a bit later
[07:13] <WaterSevenUb> carlos, apparently "Time Zone Configuration" stage and "Ubuntu Configuration" graphical interface in post-install, in breezy installation are not translatable... do you have any idea?
[07:18] <zyga> WaterSevenUb: did you check that they are not translatable?
[07:23] <WaterSevenUb> zyga, well Kamione pointed me out  some packages like debconf and timezone but those are already translated so if everything was ok they should appear already in the installation phase translated.
[07:23] <zyga> WaterSevenUb: okay
[07:24] <zyga> WaterSevenUb: it's pretty easy to check if something is not marked BTw
[07:24] <WaterSevenUb> zyga, damn... I've to go again.... well... drop me a message if you find something meanwhile. It's ugly to see that in the installation phase so I hope we can solve that:)
[07:24] <zyga> WaterSevenUb: wait
[07:24] <WaterSevenUb> zyga, k
[07:24] <zyga> WaterSevenUb: where are the daily cd tests?
[07:24] <zyga> WaterSevenUb: I'd like to test install too
[07:26] <WaterSevenUb> zyga, what I am doing now is download the ISO from, http://cdimage.ubuntulinux.org/daily/20050830.1/ or nearby :) and then use rsync to download the difference among different builds. Then I burn the ISO into a CDRW.
[07:26] <WaterSevenUb> zyga, I really have to go... if you find difficulties let me know.
[07:26] <zyga> WaterSevenUb: thanks
[07:27] <kiko> wiwiwiw
[07:40] <kiko> SteveA?
[07:41] <SteveA> kiko: code reviewing with bjorn
[07:41] <kiko> quick question
[07:41] <kiko> I have a main tree which has the sourcecode and lib creatures all checked out into it
[07:42] <kiko> I made a little script which allows you to just link from a new tree (you just branched to) to the main tree's lib/sourcecode creatures
[07:42] <kiko> a) can it go into RF utilities/* b) what should I name it?
[07:43] <Kinnison> mpt: were you smoking someone's toejam at the time?
[07:43] <kiko> what is toejam?
[07:45] <SteveA> kiko: i did this.  it will cause pybaz tests to fail.  wouldn't recommend it right now.
[07:45] <SteveA> ddaa knows about the issue.
[07:45] <kiko> SteveA, it all works for me, oddly
[07:45] <SteveA> basically, python's inspect module fails
[07:45] <kiko> interesting
[07:45] <kiko> I've always done this -- is this a recent regression?
[07:45] <SteveA> bjorn says if he rebuilds the .pycs then it works
[07:45] <SteveA> so, i always got errors
[07:45] <SteveA> bjorn gets errors at first
[07:45] <SteveA> i think ddaa should fix the code
[07:46] <SteveA> not to depend on inspect
[07:46] <SteveA> lifeless thinks so too
[07:46] <kiko> yeah.
[07:46] <SteveA> anyway, symlink-the-crack ?
[07:46] <kiko> symlink-externals?
[07:46] <SteveA> i think 'externals' has a different meaning in some senses
[07:47] <SteveA> symlink-launchpad-trees
[07:47] <kiko> what I like about externals is that it is both external and externals :-)
[07:47] <kiko> okay, I'll think about it, thanks
[07:50] <SteveA> you MUST include the word 'crack' in the name.
[07:51] <kiko> I prefer not to comment
[07:55] <carlos> kiko, language pack tarball is ready....
[07:56] <carlos> kiko, time to test it :-P
[07:56] <kiko> wooo!
[07:57] <carlos> hmm
[07:57] <carlos> no, still dumping the mapping file
[07:57] <Kinnison> carlos: could any of the problems I'm seeing in dogfood be related to not running the scripts in database/schema/pending ?
[07:57] <carlos> Kinnison, no, the problem you see is not related with db
[07:57] <carlos> but python code
[07:58] <carlos> look at lib/canonical/launchpad/browser/rosetta.py
[07:58] <carlos> Kinnison, dogfood does not have the right code
[07:58] <carlos> there
[07:59] <Kinnison> carlos: still? even though I've thrown away the entire revision library?
[07:59] <kiko> hmm, why can't I access dogfood?
[07:59] <kiko> You don't have permission to access / on this server.
[07:59] <carlos> Kinnison, https://dogfood.ubuntu.com/errors/showEntry.html?id=1125683976.170.081277828933
[08:00] <carlos> Kinnison, that bt is related to the same problem
[08:00] <carlos> a missing method inside rosetta.py
[08:00] <kiko> which is in rocketfuel head
[08:01] <Kinnison> I checked out an utterly fresh tree just hours ago
[08:01] <carlos> Kinnison, check it your self
[08:01] <carlos> get a fresh checkout as your own user
[08:02] <carlos> and compare it with launchpad's checkout
[08:02] <kiko> Kinnison, utterly stale more likely :-)
[08:03] <Kinnison> kiko: I am very confused by this
[08:03] <Kinnison> kiko: I blew away the tree and the revision library
[08:03] <Kinnison> I'm going to do as fresh a checkout of launchpad dogfood as I know how, give me a few...
[08:06] <carlos> Kinnison, did you check with a bazaar guy?
[08:07] <Kinnison> let's wait until this checkout is done, then can you please look at the relevant files and tell me if they've been updated right?
[08:07] <carlos> ok
[08:08] <SteveA> kiko: bjorn and i reviewed those branches you sent me
[08:08] <SteveA> all approved, in fact
[08:08] <bradb> SteveA: do you have about 5 mins to discuss BugRelatedObjectAddView and BugRelatedObjectEditView?
[08:09] <niemeyer> jblack: I'm reading a few of your mini-howtos
[08:09] <niemeyer> jblack: You rock :)
[08:09] <kiko> SteveA, I see all, I hear all
[08:09] <jblack> Glad you like them. I'm working on bzr ones.
[08:11] <carlos> WTF
[08:11] <carlos> kiko, the script died and the tarball was not dumped!!! :-(
[08:11] <carlos> aaaaaaaaaarrrrrrrgggggg
[08:11] <kiko> carlos, OOM perhaps?
[08:11] <carlos> OOM?
[08:12] <carlos> Out of Memory?
[08:12] <carlos> don't think so
[08:12] <carlos> it was only 200MB or so
[08:12] <Kinnison> naah, there's no OOM in the kernel logs
[08:12] <carlos> kiko, well, let's try a hoary update
[08:12] <carlos> it's smaller
[08:13] <carlos> and will help us to check if the whitespace issue is finally gone...
[08:14] <kiko> Kinnison, on staging?
[08:14] <kiko> I guess
[08:14] <SteveA> bradb: i will do shortly
[08:14] <kiko> SteveA, are we allowed to do sequence unpacking in templates?
[08:14] <bradb> ok, thanks
[08:14] <niemeyer> There's a virus eating my disk space!
[08:14] <niemeyer> Oh no.. it's baz.. sorry..
[08:14] <SteveA> kiko: not sure what you mean
[08:14] <kiko> SteveA, is there an alternative to it that is less nasty?
[08:14] <kiko> a, b = foo()
[08:14] <SteveA> in a page template?
[08:14] <kiko> yeah
[08:15] <SteveA> seeing as you don't have assignment in a page template...
[08:15] <kiko> I suspect the proper answer here is using a zope3 widget, salgado.
[08:15] <kiko> SteveA, uhm.
[08:18] <Kinnison> kiko: carlos was running the script on mawson I thought
[08:18] <kiko> Kinnison, nah, it's all staging, the database is ours!
[08:19] <Kinnison> carlos: dogfood scripts are just running the db checks
[08:19] <Kinnison> carlos: so the codebase is in place if you want to look for me
[08:19] <carlos> sure
[08:20] <carlos> Kinnison, this time, it seems to be ok
[08:20] <carlos> at least the method is there
[08:22] <salgado> kiko, huh?
[08:26] <kiko> salgado, the tuple unpacking thing
[08:26] <cprov> eu
[08:26] <cprov> sorry
[08:27] <kiko> SteveA, isn't there a len()-style tales formatter, or a shortcut to avoid having to do python: len() in a template?
[08:27] <SteveA> yes
[08:27] <SteveA> as documented in tales.txt
[08:28] <kiko> I knew it!
[08:38] <carlos> kiko, I think it's  foo/count:len
[08:40] <kiko> yeah
[08:40] <salgado> carlos, yes, it's that. thanks. :)
[08:42] <Kinnison> carlos: Right, dogfood lp instance starting up
[08:44] <Kinnison> carlos: and the front page still doesn't work :-(
[08:46] <SteveA> lifeless: ping.  pqm hates my gpg signature.
[08:47] <bradb> SteveA: what ended up being the problem with the .inTeam thing from yesterday?
[08:49] <SteveA> bradb: my experimental sqlobject / sqlos cleanups
[08:49] <SteveA> maybe i'm revealing a bug in them, or maybe my cleanups are wrong.
[08:49] <SteveA> i reverted to the rocketfuel trees for now
[08:49] <carlos> Kinnison, no idea what's going on there...
[08:49] <bradb> ah :)
[08:52] <niemeyer> How many hours a complete launchpad checkout usually takes? :)
[08:53] <kiko> niemeyer, it's usually pretty quick
[08:53] <bradb> a build-config is pretty quick/
[08:53] <bradb> s|/|?|
[08:54] <bradb> SteveA: !
[08:54] <bradb> will you have a chance to discuss those views i mentioned? it's pretty straight-forward, i think
[08:54] <SteveA> speak!
[08:54] <bradb> ok, so, two small points before i start
[08:55] <bradb> 1. I'm about to tell you something I did to keep things simple using the (code) tools that were available to me.
[08:55] <SteveA> the clock is running
[08:55] <bradb> 2. I think I have an idea for a much nicer way to do it, but we don't have to discuss that today
[08:55] <bradb> so:
[08:55] <bradb> bugs have objects related to them: cve refs, watches, links, etc.
[08:55] <bradb> "bug-related objects"
[08:55] <bradb> bug-related objects have add and edit screens
[08:56] <bradb> currently, the add screens are at: $bugpage/foos/+new
[08:56] <bradb> and the edit screens are at: $bugpage/foos/NN/+edit
[08:56] <bradb> both add pages and edit pages need bug portlets on them
[08:57] <bradb> e.g. the add attachments screen should show you the actions portlet, the bug details portlet and the attachments portlets, and maybe other things
[08:57] <bradb> same idea with edit pages, etc.
[08:57] <bradb> i.e. these pages need access to a bug
[08:57] <bradb> the problem is, there context is not a bug
[08:57] <bradb> there context is a *Set object
[08:57] <bradb> so, i created a lightweight add/edit view for these pages, that has a .bug attribute
[08:58] <SteveA> they're ?
[08:58] <bradb> BugRelatedObject{Add,Edit}View
[08:58] <BjornT> bradb: i've updated BugAndTaskPageURLs with some URL changes to be made
[08:58] <bradb> each page uses this view class, because they don't (yet) need to do anything more specific
[08:59] <bradb> SteveA: is it ok to construct a small few line view class for all these add/edit pages, to give them a simple way to access the bug, so that they can, for example, render bug portlets on their page?
[08:59] <bradb> BjornT: ! ok, thanks :)
[09:00] <SteveA> bradb: there's going to be something much better than that soon, similar to the launchbag, but actually rather better, and simpler.
[09:00] <bradb> SteveA: (like i say, i can think of what i perceive to be a more elegant way to do it, request/launchbag:bug/@@+portlet-actions, instead of view/bug/@@+portlet-actions, but...)
[09:00] <bradb> SteveA: is my solution acceptable for right now?
[09:01] <SteveA>   request/nearest:IBug/@@+portlet-actions
[09:02] <SteveA> where does your code get the 'bug' value from?
[09:02] <bradb> the launchbag
[09:04] <SteveA> in the view class's __init__ ?
[09:05] <bradb> yes
[09:05] <SteveA> yes, that's fine.
[09:05] <bradb> ok, thanks
[09:05] <kiko> SteveA
[09:05] <kiko> can you call me while you go?
[09:05] <SteveA> ok
[09:08] <carlos> kiko, the export is being really slow...
[09:08] <carlos> kiko, and I need to leave now
[09:09] <carlos> kiko, I will leave the breezy tarball running
[09:09] <carlos> so I have it on Sunday night
[09:09] <bradb> their seems to have been a mispelling spree up they're in my scrollback
[09:11] <carlos> enjoy your weekend!
[09:14] <niemeyer> kiko: There's a minor bug in src/zope/interface/_zope_interface_coptimizations.c
[09:14] <niemeyer> kiko: Which is already fixed upstream
[09:14] <niemeyer> kiko: What's the procedure to get it fixed in our tree?
[09:15] <niemeyer> .. in one short sentence
[09:15] <niemeyer> :))
[09:16] <bradb> niemeyer: Unless it's critical, it probably means waiting until we decide to upgrade to a Zope 3 release that includes that fix.
[09:16] <niemeyer> bradb: gcc 4.0 refuses to build it
[09:16] <niemeyer> Is that critical?
[09:18] <bradb> niemeyer: it depends. By way of indirection, RocketFuelSetup says that ubuntu hoary gcc is required.
[09:19] <bradb> which is 3.3.5
[09:19] <bradb> If gcc 4.0 is your only compile option, I'll hand this one off to SteveA or kiko :)
[09:20] <niemeyer> I knew I should have heard my mother.. "Stick to the standards!"
[09:20] <niemeyer> :)
[09:20] <bradb> You're trying to run Breezy, I take it?
[09:20] <niemeyer> bradb: As I said, it's a minor, so if it's not a problem for others, I'll just patch my own tree (as I just did)
[09:20] <niemeyer> Indeed
[09:21] <bradb> niemeyer: Patching your own tree seems reasonable, as long as you don't start experiencing other versioning problems that us law-abiding Hoary users aren't. :P
[09:26] <kiko> niemeyer, you need to talk to SteveA or stuart -- it's not a problem landing fixes in our zope3 tree that are already present upstream, IME
[09:27] <niemeyer> kiko: Ack
[09:30] <niemeyer> It's a one-liner
[09:32] <niemeyer> Interesting.. baz diff does not recurse into external archives
[09:33] <kiko> that's correct
[09:36] <kiko> I wonder if mark fixed that one as well
[10:09] <sivang> guys, can anyone subscribe to the launchpad list?
[10:13] <mpt> cprov: Does your branch involve any changes to configure.zcml?
[10:15] <cprov> mpt: new file, builder.zcml, if my mind still fresh
[10:15] <mpt> The entire configure.zcml was a merge conflict for me
[10:18] <cprov> mpt: are you merging back from me ?
[10:19] <cprov> mpt: as the comment says I've got a strange conflict in resources.zcml, duplicated entries
[10:19] <kiko-afk> sivang, I asked stub about this yesterday; it's currently not open but we should reconsider it
[10:19] <kiko-afk> sivang, tell me about what you're looking for and I'll see what I can do
[10:19] <mpt> cprov: Merging from rocketfuel at the moment
[10:20] <cprov> mpt: let me try too
[10:20] <mpt> someone decided to change the indentation of the file
[10:23] <mpt> cprov: Is the sampledata shown in your screenshots now in the branch?
[10:24] <cprov> mpt: no way, it's the real world !
[10:25] <mpt> darn
[10:25] <cprov> mpt: sampledata won't offer nice time-releated results.
[10:25] <sivang> kiko-afk: thanks :)
[10:26] <mpt> cprov: true enough ... it's just a bit hard to see what I'm doing
[10:29] <cprov> mpt: indeed, I'm sending you a patch to use the already populated DB in gwyddion
[10:30] <mpt> thanks
[10:34] <cprov> mpt: sent
[10:34] <cprov> mpt: let me know if it works, I'll be around, ping me
[10:35] <mpt> ok
[10:50] <cprov> mpt: did it work ?
[10:51] <mpt> cprov: still mergin
[10:51] <mpt> h
[10:51] <mpt> g
[10:52] <cprov> mpt: I did a merge in the same tree, it took about 5 min ...are you using --star-merge ?
[10:53] <mpt> cprov: no, normal merge
[10:54] <cprov> mpt: uhm .. from RF use --star-merge, faster and does the job
[10:58] <niemeyer> Yes! I have my own launchpad!
[10:58] <niemeyer> :)
[11:01] <cprov> niemeyer: so, launch ;)
[11:02] <niemeyer> Right! I'll launch myself to a coffee..
[11:02] <niemeyer> :)
[11:19] <sivang> hmm , launchpad integratino links seems to be done, is going rework or something?
[11:19] <sivang> I'm getting a system error each time I try it
[11:42] <bradb> later all
[12:02] <Kinnison> g'night all
[12:02] <lifeless> SteveA: forward me the error