[12:07] <kiko> hey 
[12:07] <kiko> does anyone know how to rebuild the fti in sampledata?
[12:07] <kiko> I copy and pasted and now I have bogus data in the fti fields
[12:08] <salgado> it's updated by a trigger
[12:08] <kiko> okay so far
[12:08] <salgado> so you can insert whatever you want without fti and it'll generate the fti for you
[12:08] <kiko> do I need to explicitly clear the field?
[12:08] <salgado> maybe not
[12:09] <kiko> what do I do? make schema?
[12:10] <lifeless> kiko: make sampledata
[12:11] <kiko> not newsampledata?
[12:12] <lifeless> meh, probably
[12:12] <lifeless> make schema loads -> database
[12:12] <lifeless> make newsampledata unload -> disk
[12:12] <kiko> and how do I get fti generated? 
[12:12] <kiko> make schema?
[12:14] <kiko> what's wrong with pqm, btw? it hasn't hung once today
[12:15] <kiko> I think it's not really running tests
[12:15] <kiko> just pretending to
[12:16] <salgado> triggers are disabled to load sampledata
[12:16] <salgado> so a make schema won't do it
[12:16] <kiko> what do I need to do?
[12:17] <salgado> copy the insert lines and paste them into psql
[12:17] <salgado> :)
[12:17] <kiko> ok
[12:17] <lifeless> kiko: launchpad test suite got fixed - I talked with spiv, SteveA and JamesH at london
[12:17] <lifeless> kiko: then jamesh fixed it
[12:17] <kiko> wow
[12:17] <kiko> was it always the same hang?
[12:18] <lifeless> the external processes is what fucked it over
[12:18] <lifeless> the ones that daemonised
[12:18] <lifeless> so the process group killer could not kill them
[12:19] <lifeless> what would happen is some failures would not teardown 'right'
[12:19] <lifeless> then there would be a stale process connected to the db
[12:19] <lifeless> after that, every test run was doomed
[12:24] <kiko> FAILED (errors=46)
[12:24] <kiko> I think ddaa will be unhappy
[12:28] <lifeless> muhahha
[12:28] <kiko> pqm has been nice to me today
[12:33] <lifeless> food!
[12:33] <lifeless> back soon
[12:39] <kiko> food, bah, what a wimp!
[12:39] <kiko> real hackers don't eat
[12:39] <kiko> they live off prana
[12:43] <dilys> Merge to devel/launchpad/: [trivial]  Add a harness Makefile target for the sake of convenience and my wrists (r3418: kiko)
[12:56] <sgt_pepper> i need ubuntu's cds 
[12:56] <kiko> sgt_pepper, shipit.ubuntu.com
[12:57] <sgt_pepper> thank kiko
[12:57] <kiko> sure
[01:00] <sgt_pepper> ubuntu have suport openoffice2.0?
[01:03] <Burgwork> sgt_pepper, yes
[01:06] <sgt_pepper> thank Burgwork
[01:06] <Burgwork> sgt_pepper, np
[01:09] <elmo> kiko: ping?
[01:09] <kiko> elmo, pong
[01:10] <elmo> ah, never mind sorry, I'm being an idiot
[01:10] <kiko> never
[01:11] <kiko> but I should roll home if I am to not miss my swimming tonight
[01:11] <kiko> catch you all later
[01:15] <lifeless> tchau
[01:16] <sgt_pepper> join #glud
[01:16] <sgt_pepper> ./join #glud
[01:21] <dilys> Merge to devel/launchpad/: [trivial]  Last part of bug 30500: fix package searching for distroarchrelease, allowing us to match on non-ftiable values such as 'at'. Includes test, yay (r3419: kiko)
[01:43] <elmo> ok, wtf
[01:44] <elmo> how can adding a 3rd table to a from clause (no where clause at all) make a select return no results?
[01:44] <elmo> literally, 'select * from foo, bar;' works, 'select * from foo, bar, bat;' returns no rows
[01:45] <lifeless> mmm, is there a relation ?
[01:45] <elmo> how do you mean?
[01:47] <lifeless> if you do a \d bat in psql, is there a constraint between the tables
[01:47] <elmo> no, nothing, they're throwaway tables I just created
[01:50] <lifeless> so, I never use that syntax ;). Try adding a full outer join perhaps;
[01:52] <elmo> hmm, I'm wondering if I'm shooting myself in the foot by calling the table 'temp' ;)
[01:52] <lifeless> uhm
[01:52] <lifeless> perhaps ;0
[02:00] <mbp_> hi all
[02:05] <lifeless> morning
[02:26] <lifeless> spiv: are you blocked on anything for the doc-bazaar review ?
[02:30] <elmo> spiv: you broke my nagios again
[02:30] <lifeless> elmo: what went down ?
[02:34] <spiv> lifeless: https://lists.ubuntu.com/mailman/private/launchpad-reviews/2006-March/002580.html is still unanswered.  You've told me (although Steve still hasn't replied to my emails directly) that the format is acceptable, but I'm still not sure that doc/ in launchpad is a better location than the wiki.
[02:34] <spiv> elmo: Hmm, that's surprising.  I'll take a look.
[02:34] <elmo> spiv: it's specific, I'm no longer getting salt info, back I think
[02:34] <elmo> that may be considered a feature, I dunno
[02:34] <elmo> check_authserver - FAIL: missing salt from returned data 
[02:35] <spiv> Oh, I see.
[02:35] <spiv> Yeah, it's returning v2 stuff from /RPC instead of v1.
[02:35] <spiv> Not that anything is still using v1 that I know of...
[02:36] <elmo> what's the difference between v2/v1?
[02:37] <spiv> elmo: see the comment near the top of https://wiki.launchpad.canonical.com/AuthServerAPI
[02:37] <elmo> cool, thanks
[02:37] <lifeless> spiv: do you know how annoying links to password-requiring-archives-are ?
[02:37] <lifeless> spiv: i.e. whats the date & title
[02:37] <spiv> lifeless: my browser auto-completes them, so no, I don't :P
[02:37] <lifeless> spiv: mine hates me
[02:38] <spiv> lifeless: March 6 and "david/launchpad/doc-bazaar"
[02:38] <elmo> teams ['[{'displayname': 'Louise McCance-Price', 'id': 99, 'name': 'name99'}] '] 
[02:39] <lifeless> lulu!
[02:39] <elmo> oh, right,that's by design
[02:39] <elmo> how weird
[02:42] <lifeless> spiv: if you get stuck like this again, please bounce the branch to me.
[02:42] <spiv> lifeless: Ok.
[02:43] <lifeless> spiv: your questions boiled down to 'I cant review this without someone else taking a decision' - which is fine, but while its in your queue, I'll be heckling *you* rather than the person you are blocked on.
[02:43] <lifeless> now I've made it steves problem
[02:44] <lifeless> sweet 
[02:44] <lifeless> we are down to 2 days as the oldest outstanding unreviewed branch, modulo kikos which I know about
[02:44] <lifeless> now to sustain it
[03:59] <mpt> Gooooooooooooooooooooooooood afternoon Launchpadders!
[04:01] <lifeless> that was fast
[04:32] <mpt> lifeless, every time I've tried to land a branch in the past two days, PQM says "database creation failed: ERROR: source database "launchpad_ftest_template" is being accessed by other users"
[04:36] <stub> It would actually say a heck of a lot more than that - please paste the output
[04:39] <mpt> when I submit it to Kinnison's paste service I get an empty page in response
[04:39] <mpt> hmm, maybe it's too big
[04:39] <mpt> no, fails with a shorter one too
[04:42] <lifeless> mpt: there is a bug in your branch - other branches are landing find
[04:42] <lifeless> *fine*
[04:42] <mpt> All the tests are passing
[04:43] <lifeless> mpt: try 'make check_merge'
[04:43] <lifeless> I can nearly guarantee that that will break.
[04:44] <mpt> I thought make check_merge was what PQM did
[04:44] <lifeless> it is
[04:44] <mpt> and PQM says all tests passed
[04:45] <lifeless> there are multiple things that emit 'tests passed' output
[04:45] <lifeless> the only thing that /matters/ is the return code from 'make check_merge'
[04:45] <lifeless> if that is 0 - your branch lands. if its not, its rejected.
[04:47] <mpt> right, but if make check_merge gives me exactly the same output, it's not going to help, because it's not telling me where the failure is
[04:48] <lifeless> mpt: well its often easier to debug when you can look for active processes, etc locally
[04:53] <mpt> No module named vfs.ivfs
[04:53] <mpt> Oh, I don't have twisted in this branch yet
[04:53] <mpt> but PQM does, so that's not the problem...
[06:14] <dilys> Merge to devel/launchpad/: [trivial]  Add options.verbose flag to script verbosity setup (r3420: Stuart Bishop)
[06:49] <mpt> Well, that was interesting
[07:10] <mpt_> lifeless, https://chinstrap.warthogs.hbd.com/~dsilvers/paste/fileEhBDDm.html
[07:10] <mpt_> There's just one error, near the bottom, which I'm pretty sure is nothing to do with me
[07:10] <mpt_> (my branch is just template changes)
[07:13] <mpt_> and it's not the same error as PQM gave
[07:13] <lifeless> mpt_: ok. so you've done a diff against rocketfuel and it shows you just the simple diff you expect ?
[07:13] <mpt_> yes, just did that
[07:14] <mpt_> three templates, one zcml, one line in a view class
[07:19] <lifeless> what was the exit code you got from make check_merge (you can echo $? straight after - and only straigh after) to find out
[07:20] <lifeless> also that does not appear to be the full test run - it stops where I would expect the importd tests to start.
[07:53] <dilys> Merge to devel/launchpad/: [trivial]  Explains products on /products, and fixes a typo on /projects. (r3421: Matthew Paul Thomas)
[07:54] <mpt> oh really!
[07:55] <mpt> So the only difference between an unsuccessful and a successful merge was changing two templates from 2col back to 3col?
[07:55] <mpt> hmmmmmmmmmmmm
[07:56] <spiv> mpt: I suspect that's just co-incidence...
[07:59] <mpt> indeed
[07:59] <mpt> especially since there were no pagetest failures
[09:18] <carlos> morning
[09:23] <mpt> hi carlos 
[09:23] <carlos> mpt: hey dude
[09:50] <carlos> lifeless: hi, around?
[09:50] <lifeless> yup
[09:51] <lifeless> gmorning
[09:51] <carlos> lifeless: did you remove my AJAX branch that steve had on his queue?
[09:52] <carlos> talking about PendingReviews
[09:52] <lifeless> nope
[09:52] <lifeless> he did
[09:52] <carlos> ok
[09:52] <lifeless> look in the pending reviews history
[09:56] <sabdfl> mpt: ping
[10:02] <mpt> sabdfl, pong
[10:03] <mpt> just about to reply to your mail
[10:03] <sabdfl> mpt: evening
[10:18] <mdke_> carlos, got time for 2 questions about rosetta?
[10:19] <carlos> mdke_: I always have time for you ;-)
[10:19] <mdke_> carlos, heh :) ok.
[10:19] <mdke_> 1. when a package is uploaded with a new pot, how long does it take for rosetta to add the pot?
[10:19] <mdke_> does anything need to be done manually?
[10:21] <carlos> mdke_: the first time we see that .pot file, we need to approve it
[10:21] <carlos> mdke_: next time, it's imported automatically
[10:22] <carlos> mdke_: unless we decided to block it
[10:23] <mdke_> carlos, thanks, ok I'll come to you for some approval
[10:24] <mdke_> carlos, second question, which I think you just answered, if the same pot file appears in two packages, is rosetta clever enough to figure that out?
[10:24] <carlos> mdke_: I look at the queue all days, so it should not take more than one day (we have some backlog from kde, but that was a special case)
[10:24] <carlos> mdke_: in two packages?
[10:24] <mdke_> yes
[10:25] <carlos> mdke_: well, rosetta is not able to figure it automatically if it's on two different packages
[10:25] <carlos> it depends if I remember that I saw it before...
[10:25] <mdke_> carlos, but you can approve one, and disapprove the other?
[10:25] <jordi> mdke_: in general, for approvals, you can come to me too
[10:25] <jordi> and let carlos do  the hacking :)
[10:25] <mdke_> jordi, ok, I will
[10:25] <carlos> yeah ;-)
[10:26] <mdke_> carlos, a concrete example. the pot file for the ubuntu server guide is likely to be in both the ubuntu-docs and kubuntu-docs source.
[10:26] <carlos> mdke_: If you warn us, we can block one of them and leave the other available to translate
[10:27] <mdke_> the template is already in rosetta under ubuntu-docs
[10:27] <mdke_> i'll upload a newer template soon
[10:27] <carlos> mdke_: should we block the one from kubuntu-docs?
[10:27] <mdke_> carlos, great. I hereby warn you: don't accept serverguide.pot for kubuntu-docs :)
[10:27] <mdke_> also, can you remove pot files?
[10:27] <carlos> jordi: ^^^^
[10:27] <carlos> mdke_: yes, I can, is not easy, but I will do a batch removal soon
[10:28] <mdke_> carlos, shall I give you the ones to remove over irc, or by email?
[10:28] <jordi> ok :)
[10:29] <jordi> email generally works better :)
[10:30] <mdke_> rosetta@ubuntu.com?
[10:30] <carlos> mdke_: rosetta@launchpad.net is better
[10:32] <mdke_> carlos, will do. Thanks
[10:35] <mdke_> carlos, jordi, thanks for help.
[10:37] <carlos> mdke_: you are welcome
[10:47] <carlos> mdke_: should we block the templates you asked us to remove or did you remove them from that package?
[11:08] <seb128> carlos: grumpf, I just uploaded a gnome-session current potfile over the hoary one due to rosetta :p
[11:08] <seb128> carlos: https://launchpad.net/products/gnome-session/+translations ... why the heck does it default to "hoary"?
[11:09] <carlos> seb128: because someone added the link from hoary to the product
[11:09] <carlos> and no one added the link from breezy or dapper
[11:09] <seb128> hum, that's just confusing :/
[11:10] <seb128> if I don't manager to use it, I bet that users are having an hard time trying
[11:11] <carlos> seb128: right, but you should also read!!!
[11:11] <carlos> :-P
[11:11] <seb128> I just want to translate gnome-session
[11:11] <carlos> seb128: what did you expect there?
[11:11] <seb128> so I went on rosetta page
[11:11] <seb128> pick gnome-session to the list
[11:11] <seb128> picked french
[11:11] <seb128> and uploaded my po
[11:12] <seb128> I expected translating the current Ubuntu
[11:12] <carlos> seb128: but what version of gnome-session ?
[11:12] <seb128> not hoary which one year old
[11:12] <carlos> well, hoary is still supported...
[11:12] <seb128> whatever is current
[11:12] <seb128> yeah, but default should be current
[11:12] <carlos> current == breezy not dapper
[11:12] <carlos> just in case...
[11:12] <seb128> that's like we don't set tasks on hoary by defaulf when you file a bug :p
[11:12] <carlos> we defined a way to improve this situation las month while the london sprint
[11:13] <seb128> I disagree with the current, but that's arguable
[11:13] <seb128> the fact is 
[11:13] <seb128> people go to https://launchpad.net/rosetta
[11:13] <carlos> seb128: at some point, we will move from breezy to dapper, before release
[11:13] <seb128> they want to translate gnome-sessio, they pick it
[11:13] <seb128> you get https://launchpad.net/products/gnome-session/+translations
[11:13] <seb128> click on french
[11:13] <carlos> dude
[11:14] <seb128> you get https://launchpad.net/distros/ubuntu/hoary/+source/gnome-session/+pots/gnome-session-2.0/fr/+translate
[11:14] <carlos> I know users don't read...
[11:14] <carlos> Rosetta is the primary translation system for the Ubuntu distribution. You can help translate any application in Ubuntu, or any of the Ubuntu derivative distributions, using this Web interface. Select a release to start translating.
[11:14] <carlos> you select the distribution you want to translate
[11:14] <carlos> the others are products
[11:14] <seb128> where?
[11:14] <carlos> launchpad.net/rosetta
[11:14] <seb128> https://launchpad.net/products/gnome-session/+translation only list hoary
[11:14] <seb128> no breezy
[11:14] <seb128> no dapper
[11:14] <carlos> because you selected a product
[11:14] <seb128> I went to https://launchpad.net/rosetta
[11:15] <carlos> when we import GNOME's CVS, you will get GNOME CVS there, instead of Ubuntu
[11:15] <seb128> and selected what I want to translate
[11:15] <carlos> seb128: but please, read! ;-)
[11:15] <seb128> I'm not stupid, I figured and fixed the pot
[11:15] <carlos> seb128: I know it's needs to be improved
[11:15] <seb128> my point was about the UI not being good
[11:15] <carlos> s/it's/it/
[11:15] <seb128> you don't agree I'll stop here
[11:15] <carlos> seb128: I agree
[11:15] <seb128> but I still think most people will just click
[11:15] <seb128> and go to the wrong place
[11:15] <carlos> I already told you that, and that's why we are going to change it
[11:15] <seb128> cool :)
[11:16] <seb128> maybe a transition page "pick what version you want translate"
[11:16] <carlos> but the main problem here is the fact that people don't read :-)
[11:16] <seb128> with the distro branches and upstream product listed
[11:16] <seb128> you have to do with that
[11:16] <seb128> that's why GNOME put verbs on the buttons for its dialogs by example
[11:16] <LarstiQ> carlos: I'd be grateful if you could solve that problem
[11:17] <seb128> you will not change users, you have to live with the fact than most don't want to read your blabla
[11:17] <seb128> and that the UI should make easy to go to the right place for those who don't read
[11:17] <carlos> yeah
[11:17] <seb128> a page when you click on the product
[11:18] <seb128> Pick what version of the product to translate:
[11:18] <seb128> * hoary
[11:18] <seb128>  * breezy
[11:18] <seb128> * dapper
[11:18] <seb128> * upstream
[11:18] <seb128> would be good enough
[11:19] <carlos> seb128: anyway, we still depend on people linking sourcepackages with products
[11:20] <seb128> :/
[11:20] <carlos> that will be solved when hct is in place because you will need to do that link to work with your packages. ATM, Rosetta is the only one using it....
[11:20] <carlos> https://launchpad.net/products/gnome-session/+translations
[11:21] <carlos> if you look at the portlet on the right
[11:21] <carlos> there, you will get the list of distributions that have gnome-session
[11:21] <carlos> to translate
[11:21] <seb128> cool
[11:21] <carlos> and the main page will show the one where the translation focus should be
[11:22] <carlos> seb128: that functionality is already there
[11:22] <carlos> but needs someone to maintain the links
[11:22] <carlos> anyway, as said... we are going to improve it a bit
[11:22] <seb128> right
[11:22] <seb128> another question
[11:22] <seb128> do I have a way to know who updated gnome-session-2.0 fr.po and when?
[11:25] <carlos> seb128: https://launchpad.net/distros/ubuntu/breezy/+source/gnome-session/+pots/gnome-session-2.0/fr/
[11:25] <carlos> that shows you who translated 
[11:25] <carlos> we are not showing dates
[11:25] <carlos> but we have that information in our database
[11:25] <carlos> so it's a matter of adding it to our UI
[11:26] <carlos> I was working on a UI to expose that information
[11:26] <seb128> would be nice
[11:26] <carlos> when I had to focus on language packs
[11:26] <seb128> k
[11:26] <carlos> so as soon as language packs are rocking, I will finish that
[11:26] <seb128> another question and that should be enough for now
[11:26] <carlos> ok
[11:26] <seb128> when is planned a search feature?
[11:26] <seb128> like I dont want to browse 40 pages of translation to find the string I want to fix
[11:27] <seb128> and I don't want to wait on rosetta sending me a po by mail so I can fix and upload it back :p
[11:27] <carlos> the spec wasn't approved, we need to work a bit more on it and get it approved before I can work on it
[11:27] <carlos> I cannot give you a date, sorry
[11:28] <seb128> so that's not "soon"
[11:28] <seb128> k, thank you
[11:28] <carlos> you are welcome
[11:29] <seb128> BACK TO WORK
[11:29] <seb128> ups, capslock :p
[11:31] <carlos> seb128: :-D
[11:47] <mdke_> carlos, I've removed them from the packages
[11:47] <carlos> ok
[01:01] <carlos> stub: hi, where is your script to remove potemplates?
[01:12] <ddaa> MUHUWAHA!
[01:13] <ddaa> there's a package names "cvssuck" in Ubuntu now :)
[01:15] <dilys> Merge to devel/launchpad/: [trivial]  fix bug 37133, make sure MessageSet.fromEmail() doesn't blow up when parsing forwarded emails. (r3422: Bjorn Tillenius)
[01:16] <stub> carlos: chinstrap:/home/warthogs/archives/stub/dbascripts (which was an experiment that would have been better off being a Python script)
[01:16] <carlos> stub: would you add it to scripts/rosetta on rocketfuel?
[01:17] <carlos> stub: I'm adding a new script to do those kind of tasks there and I would move your script to python code later
[01:17] <carlos> and add tests for it
[01:18] <stub> It isn't suitable for general use - how 'bout I just paste it to pollute Launchpad with one less file?
[01:19] <stub> carlos: ^^^
[01:20] <carlos> ok, I will make it suitable for general use then and will add it when it's ready
[01:21] <stub> carlos: https://chinstrap.ubuntu.com/~dsilvers/paste/filesJc0mt.html
[01:22] <stub> I will redo the constraints ON CASCADE DELETE and similar, so DELETE FROM POTemplate WHERE will work. I can prioritize that if you want to make things easier.
[01:23] <carlos> stub: hmm I prefer to do the removal myself, that will prevent that we remove POTemplates if we don't realy want to do it...
[01:23] <stub> ok
[01:23] <carlos> myself == using the same procedure you did with the .sql
[01:24] <stub> score! 3 public holidays next week, not two.
[01:24] <stub> Although that would be a bit rude taking them all
[01:24] <carlos> stub: well... if those are public holidays...
[01:25] <carlos> I have two days next week (Thursday and Friday) and one more the week after that (Monday)
[01:53] <dilys> Merge to devel/launchpad/: [trivial]  fix bug 38567, make sure that the 'close support request' checkbox is visible when it should be. (r3423: Bjorn Tillenius)
[03:03] <kiko> o/~ hotline operator o/~
[03:03] <kiko> hey elmo 
[03:03] <kiko> say hi when you can
[03:03] <kiko> carlos, yeah, so do I
[03:03] <carlos> What's the equivalent to 'login' for zopeless scripts?
[03:03] <kiko> mmmm
[03:04] <kiko> I wonder if such a thing exists
[03:04] <carlos> kiko: I think you said nex meeting is on Thursday.. if most of us will be on holidays, shouldn't we move it to Wednesday?
[03:04] <kiko> thursday is not a holiday for me
[03:04] <kiko> but I am open to moving it
[03:04] <carlos> kiko: then, how could I change attributes that requiere launchpad.Edit permissions?
[03:04] <kiko> BjornT might know.
[03:04] <carlos> kiko: <kiko> carlos, yeah, so do I
[03:05] <kiko> I have holidays friday and then the other monday
[03:05] <carlos> kiko: then I don't understand that
[03:05] <carlos> oh, ok
[03:05] <kiko> it was a more or less so do I
[03:05] <carlos> ;-)
[03:05] <carlos> BjornT: around?
[03:05] <BjornT> carlos: yeah
[03:06] <carlos> BjornT: I have a zopeless script that needs to write to an attribute that is protected with: 
[03:06] <carlos>     <content class="canonical.launchpad.database.POFile">
[03:06] <carlos>         <allow interface="canonical.launchpad.interfaces.IPOFile" />
[03:06] <carlos>         <require
[03:06] <carlos>             permission="launchpad.Edit"
[03:06] <carlos>             set_schema="canonical.launchpad.interfaces.IPOFile" />
[03:06] <carlos>     </content>
[03:06] <BjornT> carlos: by default zopeless scripts are allowed to get and set attributes, as long as there is a security declaration for the attribute, so it should work. doesn't it?
[03:07] <carlos> Traceback (most recent call last):
[03:07] <carlos>   File "./scripts/rosetta/remove-upstream-translations.py", line 205, in ?
[03:07] <carlos>     sys.exit(main(sys.argv))
[03:07] <carlos>   File "./scripts/rosetta/remove-upstream-translations.py", line 165, in main
[03:07] <carlos>     pofile.latestsubmission = None
[03:07] <carlos> zope.security.interfaces.ForbiddenAttribute: ('latestsubmission', <POFile at 0x-499c1e34>)
[03:08] <carlos> with zope.Public it was working... but I changed it because those permissions were wrong
[03:08] <carlos> well, it hadn't exactly that with zope.Public, but with set_attributes + zope.Public
[03:09] <BjornT> carlos: it's because latestsubmission is an Attribute, and set_schema="...IPOFile" doesn't include Attributes
[03:09] <carlos> I think I got that problem already and had to use set_attributes...
[03:09] <carlos> that's it
[03:09] <carlos> BjornT: I see
[03:10] <carlos> BjornT: thanks
[03:11] <BjornT> np
[03:11] <carlos> BjornT: another thing I don't understand is... what's the utility of set_schema then?, if we have the same interface in allow and require... it's useless, right?
[03:11] <carlos> BjornT: I guess it's only useful if we split the interfaces between queries and modifications calls
[03:12] <BjornT> carlos: the only useful thing about it is that it looks if a field is read only, and automatically denies write to such fields. if think it would be good to have something like set_interface though. 
[03:13] <BjornT> carlos: on the other hand, we should try to avoid being lazy, and don't use Attribute as much as we do
[03:14] <sabdfl> kiko: ping
[03:14] <kiko> sabdfl, pong
[03:14] <sabdfl> good news, i think
[03:14] <carlos> BjornT: if instead of Attribute I were using, for instance, an Int(), will set_schema work?
[03:14] <kiko> there's been a surplus of those this week!
[03:14] <kiko> tell me about it
[03:15] <BjornT> carlos: yes. (although you should use Int only if the attribute is expected to be an int)
[03:15] <carlos> BjornT: yeah, I know, I said Int as an example for an Int
[03:47] <kiko> ddaa, ping?
[03:47] <ddaa> kiko: pouet
[03:47] <kiko> ah, the flying frenchman
[03:48] <kiko> carlos, have you been noticing the error output in the import and exports of KDE?
[03:48] <matsubara> staging is down again?
[03:48] <kiko> yay, yes
[03:50] <carlos> kiko: which kind of errors?
[03:50] <carlos> kiko: I'm aware that some .pot files were rejected
[03:50] <kiko> carlos, character set conversion errors, IIRC, and what else? mmmm
[03:50] <carlos> due encoding problems
[03:50] <kiko> yes
[03:50] <carlos> kiko: yeah, that's an error with the .pot file, I already reported it to riddell
[03:50] <kiko> ok.
[03:51] <carlos> thanks anyway
[03:51] <kiko> matsubara, the staging update failed, I just noticed.
[03:53] <carlos> kiko: we have also those files with the 'FAILED' status on the import queue. I'm planning to go over them to fix any issue we have until that list is empty (and remove the broken ones unrelated with Rosetta). Also, I will add an errorlog field to that table to store there the error to let other people understand why did it fail
[03:53] <kiko> that's a great idea!
[03:53] <kiko> sounds very appropriate
[03:53] <kiko> salgado, ping
[03:53] <kiko> or well I'll just go up 
[03:54] <kiko> BjornT, ping?
[03:54] <BjornT> pong
[03:54] <carlos> kiko: I can turn staging on if you want
[03:54] <salgado> yo kiko
[03:55] <kiko> carlos, I always want
[03:55] <carlos> well, execute the script to turn it on, not sure if it will fail again...
[03:55] <kiko> BjornT, seen the teammembership failure for s-b-notifications?
[03:57] <BjornT> kiko: yes, fixed in r3415. also mailed stub about it, so that he knows that when r3388 gets rolled out, this patch has to be included
[03:57] <carlos> kiko: hmm, perhaps my language pack export caused the problem with stating server....
[03:58] <kiko> BjornT, okay, thanks for confirming. did you notice the weird output the last run had?
[03:58] <kiko> it included the content-type
[03:58] <kiko> BjornT, is that normal?
[03:58] <salgado> Kinnison, around?
[03:58] <kiko> carlos, did you see the message? it was a deadlock.
[03:58] <BjornT> kiko: it was running with -v, i'm not sure why.
[03:58] <carlos> kiko: because my script is connected to the database
[03:58] <carlos> or at least that's what I think
[03:59] <kiko> carlos, ah, that is possible! can you change the time it runs, or check to see if the restore is happening?
[03:59] <salgado> I need help on bug 38247 and bug 38256
[03:59] <Ubugtu> Malone bug 38247 in launchpad "Mirror prober issues HTTP requests looking for unofficial DistroArchReleases" [Normal,Unconfirmed]  http://launchpad.net/bugs/38247
[03:59] <Ubugtu> Malone bug 38256 in launchpad "Mirror prober doesn't know how to generate the filename for binary packages whose version starts with "<some-number>:"" [Normal,Unconfirmed]  http://launchpad.net/bugs/38256
[03:59] <carlos> well, the problem is that the restore was executed after my script started
[04:00] <carlos> kiko: I need to talk with stuart to see when should I execute it...
[04:00] <kiko> carlos, I'll email him so you can chat about it, cool.
[04:00] <carlos> I already moved it from morning to the afternoon due the first update
[04:00] <carlos> I think this second update is done too early
[04:01] <kiko> carlos, well, it starts at 12:30, you know
[04:02] <Kinnison> salgado: yo
[04:02] <salgado> Kinnison, I need your help on those bugs I pasted above. :)
[04:03] <carlos> kiko: and the first one is done at 9:30 or 10:30, I'm not sure...
[04:03] <kiko> BjornT, maybe tell stub to turn -v off? also, why did this last run succeed?
[04:04] <BjornT> kiko: i'll ask him to do so if the next run is with -v as well.
[04:04] <kiko> okay.
[04:04] <carlos> WTF
[04:04] <carlos> carlos@aragorn:~/Work/Canonical/trivial$ bzr merge ../archive/rocketfuel/launchpad/
[04:04] <carlos> bzr: ERROR: exceptions.NameError: global name 'self' is not defined
[04:04] <carlos>   at /usr/lib/python2.4/site-packages/bzrlib/progress.py line 437
[04:04] <carlos>   in note
[04:04] <kiko> hah hah hah
[04:04] <kiko> you crack of the day user you
[04:04] <kiko> this may be an untested codepath!
[04:04] <BjornT> kiko: i think it succeeded, since the db was rebuilt, and the db wasn't in a state that triggered the bug (sending notifications to a team with no contact address)
[04:04] <carlos> kiko: yeah :-(
[04:05] <kiko> BjornT, of course
[04:05] <kiko> BjornT, did you add a test for the teammembership-requiring codepath?
[04:05] <BjornT> kiko: of course
[04:05] <kiko> wonderful
[04:08] <Kinnison> salgado: bug 38247 and bug 38256 ?
[04:08] <Ubugtu> Malone bug 38247 in launchpad "Mirror prober issues HTTP requests looking for unofficial DistroArchReleases" [Normal,Unconfirmed]  http://launchpad.net/bugs/38247
[04:08] <Ubugtu> Malone bug 38256 in launchpad "Mirror prober doesn't know how to generate the filename for binary packages whose version starts with "<some-number>:"" [Normal,Unconfirmed]  http://launchpad.net/bugs/38256
[04:08] <salgado> yep
[04:08] <Kinnison> salgado: the second, strip off the epoch, the filenames do not contain the epoch
[04:09] <Kinnison> salgado: We should probe for all archreleases yes
[04:09] <Kinnison> salgado: It's a very small overhead and means we can spot full mirrors
[04:09] <kiko> salgado, ask me about epoch-stripping
[04:10] <kiko> I had a recent re-encounter with this
[04:10] <Kinnison> salgado: Any idea when you'll have time to review the test branch of mine you were given?
[04:10] <salgado> can the epoch-stripping be documented somewhere or be done in a single place?
[04:10] <Kinnison> salgado: In theory, take the binarypackagerelease, find the binarypackagefile entries for it, get the filename out of the libraryfilealias
[04:10] <salgado> or I'm the only one to run into this problem?
[04:10] <Kinnison> salgado: that way you don't have to add logic, just find it in the db
[04:10] <salgado> ahhhh
[04:11] <salgado> sounds like a plan
[04:11] <kiko> ah, cool
[04:12] <salgado> Kinnison, I think I'll be able to review it today, but later
[04:12] <Kinnison> salgado: cool, I'm not in a rush, but it'd be nice to get it merged
[04:13] <Kinnison> kiko: what happened with epochs recently? anything I should know about?
[04:13] <kiko> Kinnison, elmo did epoch-stripping in the sync-source script.
[04:13] <Kinnison> kiko: aah
[04:13] <kiko> Kinnison, I was unaware of the fact that we could use binarypackagefile for that or else I'd have told him
[04:14] <carlos> matsubara: staging is alive again
[04:15] <carlos> wow, new eye candy!
[04:16] <matsubara> carlos: thanks
[04:16] <Kinnison> kiko: It sometimes takes me a moment to remember, but the filenames are all there because the publisher uses them :-)
[04:17] <kiko> yeah, of course
[04:17] <kiko> gina has no choice but elmo does
[04:20] <Kinnison> indeed
[04:46] <dilys> Merge to devel/launchpad/: [trivial]  Update sampledata and FTI which suffers from cut-n-pastry (r3424: kiko)
[04:49] <kiko> thank you dilys 
[04:49] <kiko> now where was I?
[04:51] <matsubara> ddaa: is there any use case to let a user register a hosted branch thru the web UI?
[04:52] <kiko> BjornT, time for a review for a bug you reported? it is quick and interesting and potentially a disaster :)
[04:59] <kiko> https://chinstrap.ubuntu.com/~dsilvers/paste/filelcEchA.html
[04:59] <kiko> come on BjornT be a sport
[05:00] <salgado> kiko, [BjornT]  is away (back later tonight)
[05:02] <kiko> he doesn't love me
[05:09] <Kinnison> is pqm borked?
[05:09] <Kinnison> (stale authserver or similar?)
[05:09] <kiko> not for me
[05:10] <kiko> merged some 5 landings over yesterday and today
[05:11] <Kinnison> I just sent one and got a failure
[05:11] <Kinnison> psycopg.OperationalError: FATAL:  database "launchpad_empty" does not exist
[05:11] <Kinnison> in fti.py
[05:12] <kiko> that is a race condition, see launchpad email I got from stub 
[05:12] <kiko> you will need to resubmit
[05:12] <Kinnison> okay
[05:12] <Kinnison> thanks
[05:12] <kiko> it's unfortunate but one of the lesser pqm problems because it comes back fast
[05:12] <kiko> hung processes are much more annoying
[05:12] <kiko> but they seem to be absent this week
[05:13] <Kinnison> cool
[05:13] <Kinnison> Does PQM run the checks in a chroot?
[05:13] <kiko> IIRC it does yes
[05:13] <Kinnison> If so, it could do the same trick we use to clear the chroot on the buildds
[05:13] <kiko> I think we do that
[05:13] <kiko> every time we run a PQM process
[05:13] <kiko> but IMBW
[05:13] <kiko> you can email lifeless CC: lp to ask
[05:14] <ddaa> matsubara: the user will likely want to use the web ui eventually to set the title, summary and status
[05:14] <ddaa> so being able to do it in any order is easier
[05:15] <mdke_> jordi, new ubuntu-docs with brand new pot files has been uploaded. Expecting kubuntu-docs soon
[05:15] <ddaa> matsubara: note that sabdfl's branch (that's I'm preparing for review) includes a change to the IBranch.url message to remove the reference to the fact the URL can be nullable.
[05:16] <kiko> matsubara, ddaa: well, given that, I'd forbid it to be nullable, period.
[05:16] <ddaa> kiko: well, it has to be nullable in the database :)
[05:16] <ddaa> but I'm in favour of making it required in IBranch
[05:16] <kiko> in the form funny man
[05:17] <ddaa> I'll edit the IBranch.url comment on the bazaar-ui branch to tell the user to register hosted branches by pushing the branch to bazaar.launchpad.net.
[05:18] <matsubara> ddaa, kiko: so this patch fixes bug 37885? https://chinstrap.ubuntu.com/~dsilvers/paste/filesJbUA1.html
[05:18] <Ubugtu> Malone bug 37885 in launchpad "Branch URL field doesn't properly validate input" [Normal,Confirmed]  http://launchpad.net/bugs/37885
[05:18] <ddaa> I think eventually we'll want to point to a documentation page, as the use of the sftp server cannot be made really discoverable in the web ui.
[05:19] <kiko> matsubara, in _toFieldValue, when will we have self._missing?
[05:19] <kiko> okay, I see, Required input is missing
[05:20] <ddaa> matsubara: nope
[05:20] <kiko> I thought it was a matter of changing the interface, myself
[05:21] <ddaa> The interface is correct, it's a bug in BranchAddView
[05:21] <matsubara> ddaa: why not?
[05:21] <ddaa> hu, I mean BranchUrlWidget
[05:23] <matsubara> ddaa: well, that's why I changed the BranchUrlWidget to enforce the required=True in the interface.
[05:24] <ddaa> mh... my branch here is slightly out of date...
[05:24] <matsubara> ddaa: and changed the interface description to cope with the fact that the field is required, meaning that the user now doesn't have the option to leave it blank
[05:24] <ddaa> The interface I have here says it's required, but I can reproduce the OOPS
[05:25] <matsubara> ddaa: that's the bug
[05:25] <ddaa> it looks like something fails to validate for non-empty value before calling _toFieldValue
[05:25] <matsubara> -        value = TextWidget._toFieldValue(self, input)
[05:26] <kiko> HYDRATE OR DIE
[05:26] <matsubara> if you call that with input = '' it returns None
[05:26] <ddaa> or conversely, _toFieldValue should gracefully handle None so the subsequent validation could raise the appropriate exception.
[05:28] <matsubara> that's exactly what my patch is doing.
[05:29] <ddaa> sorry, I got confused by Ubugtu, did not look at the patch :)
[05:30] <ddaa> matsubara: that one fixes the oops https://chinstrap.ubuntu.com/~dsilvers/paste/fileC0wwlp.html
[05:30] <kiko> competing fixes for the bug
[05:31] <kiko> but matsubara's fix is more correct and has tests
[05:31] <ddaa> I'm do not claim I understand what I have done there :)
[05:32] <ddaa> matsubara: you must also make sure that trailing slash in URL are properly stripped in both the +addbranch and branch/+edit forms.
[05:32] <ddaa> otherwise you leave the door open to database constraint oops
[05:33] <matsubara> ddaa: you wrote tests for that, and they're passing
[05:33] <ddaa> Oh, right, I did :)
[05:33] <dilys> Merge to devel/launchpad/: rs=stub Add a rebuildfti Makefile target, and make newsampledata use it (r3425: kiko)
[05:33] <kiko> yay yay yay
[05:34] <ddaa> I vaguely do not like the fact of duplicating the "required" information in _toFieldValue
[05:34] <ddaa> mh
[05:34] <ddaa> I do not think you are, actually
[05:34] <salgado> kiko, doesn't it take long to rebuild the fti? maybe not with our small sampledata
[05:34] <ddaa> I just cannot read that code :)
[05:34] <kiko> salgado, it takes exactly 5 seconds on my computer
[05:35] <ddaa> salgado: okay, go for it!
[05:35] <salgado> your computer is far better than mine. :)
[05:35] <salgado> me?
[05:36] <ddaa> s/salgado/matsubara/
[05:36] <matsubara> ddaa: merci
[05:36] <ddaa> those tourists, they all look the same to me ;)
[05:36] <salgado> dude, you can't even use the tab-completion-breakage as an excuse in this case
[05:37] <salgado> oh, right. indeed I look like I came from china
[05:37] <kiko> and that is usually a good excuse
[05:37] <matsubara> salgado: korea man!
[05:38] <ddaa> salgado: you see, if you cannot tell the difference between china and korea, or can you expect me to tell the difference betwen brazil? 
[05:38] <ddaa> s/or/how/
[05:40] <salgado> brazil, china, korea.. they're all the same thing. all from the same bucket
[05:40] <kiko> where is my merge request o pqm
[05:40] <ddaa> do not even mention thailandese aussies!
[05:47] <carlos> kiko: dude.... your country's spam scares me so much...
[05:47] <carlos> 1- ORKUT: ROUBE COMUNIDADES, APRENDA A PEGAR SENHA DE OUTROS USURIOS,
[05:47] <carlos> RECEBA UMA LISTA COMPLETA DE SCRIPTS PARA BARBARIZAR OUTROS USURIOS E +
[05:47] <carlos> MANDE MENSAGENS EM MASSA PARA COMUNIDADES E AMIGOS...
[05:47] <carlos> ALGUMAS FERRAMENTAS PARA ORKUT QUE VEM NO CD:
[05:47] <carlos> (ATENO ESSES PROGRAMAS SO VENDIDOS POR AI POR $150 CADA UM!!!)
[05:48] <carlos> :-P
[05:48] <kiko> it's the internet, carlos. it reflects well humanity: some of it isn't healthy.
[05:48] <carlos> kiko: yeah, I wonder who is interested on pay money for those kind of scripts...
[05:49] <salgado> "Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe."
[05:49] <carlos> well, I got my answer: "Compre j o seu CD Hacker, somente programas testados..."
[05:49] <ddaa> carlos: I recently received a spam from a student of the school I have attended, asking for an intership. In finance.
[05:49] <carlos> so they are offering it to the 'I want to be a hacker!'
[05:50] <ddaa> obviously, the bloke has just mass mailed a large section of all the former students
[05:55] <salgado> kiko, about bug 28679, I have some questions
[05:55] <Ubugtu> Malone bug 28679 in launchpad "Need email notifications when a person is approved/denied as a member of a team" [Critical,In progress]  http://launchpad.net/bugs/28679
[05:56] <salgado> should you get mailed if I add you to one of my teams without you proposing yourself first?
[05:56] <salgado> (I think so)
[05:57] <salgado> should I mail only you or you and the team admins if/when your membership expires?
[05:57] <kiko> yes and both
[05:57] <kiko> I think
[05:58] <salgado> and I think I agree
[05:58] <ddaa> kiko: where can I find the table sorting javascript?
[05:58] <jordi> mdke_: ok
[05:59] <kiko> ddaa, in contrib/templates/
[06:00] <ddaa> I'd like to put an onload on some pages to sort by a specific column.
[06:00] <kiko> is that the right solution I wonder
[06:00] <kiko> I don't think it is
[06:00] <kiko> I think the right solution is to add a hint to the table
[06:00] <ddaa> meaning?
[06:00] <carlos> time to leave
[06:00] <kiko> and having the JS when attaching itself to the table DTRT
[06:00] <carlos> see you!
[06:00] <kiko> maybe
[06:00] <ddaa> mh...
[06:00] <kiko> carlos, is it all good news?
[06:01] <salgado> kiko, should I send notifications when you join a team and is automatically approved because that team is open?
[06:01] <salgado> in this case I don't think so
[06:01] <kiko> no but the UI should say so
[06:01] <carlos> kiko: well, the script to cleanup oo took more time than I expected (bug #32610)
[06:01] <Ubugtu> Malone bug 32610 in openoffice.org "all untranslated messages imported from OOo are marked as translated" [Normal,In progress]  http://launchpad.net/bugs/32610
[06:01] <kiko> as usual!
[06:01] <dilys> Merge to devel/launchpad/: [trivial]  Add the dist-upgrader to the list of things cron.daily signs (r3426: Daniel Silverstone)
[06:02] <carlos> kiko: but other than that... I need to add tests (will do it while travelling) and ask for review to test it on mawson and execute it on production next week
[06:02] <kiko> okay
[06:02] <kiko> how are our statistics looking?
[06:02] <carlos> kiko: well, I had the SQL already done, but had to move it to python code to do it in batches so we don't lock Rosetta for 2-3 hours
[06:03] <kiko> review-breezy-ksystemlog-1
[06:03] <kiko> review-breezy-lintian-1
[06:03] <kiko> review-dapper-libidn-1
[06:03] <kiko> remember to get rid of these soon
[06:03] <carlos> kiko: I was late for today's export to add a bunch of KDE templates, but I hope tomorrow we will have them
[06:03] <carlos> kiko: yeah, don't worry
[06:03] <carlos> I'm trying to reduce the amount of entries on our import queue first...
[06:03] <kiko> I am also surprised at the list of things that are not imported/exported
[06:03] <kiko> for instance
[06:04] <kiko> wget, sed, rpm?
[06:04] <kiko> grep, gettext, cpio, discover
[06:05] <kiko> ddaa?
[06:05] <ddaa> if (((' '+thisTbl.className+' ').indexOf("sortable") != -1) && 
[06:05] <ddaa> should be indexOf(" sortable ")
[06:05] <ddaa> line 30
[06:05] <kiko> what does this affect?
[06:06] <ddaa> can match class="sortable-no-gocha"
[06:06] <ddaa> quite minor, but it's not correct
[06:06] <mdke_> jordi, can you ping me when they are all imported? I want to do a quick announcement.
[06:06] <carlos> kiko: I suppose that some of them were not uploaded using soyuz, I didn't import the translations in those cases, is more easy for me to get them from soyuz, thus, if I have work with the ones from soyuz I prefer to concentrate on them before upload manually things that perhaps will appear soon using soyuz directly
[06:06] <kiko> feel free to fix I guess
[06:06] <kiko> carlos, you are suggesting no new uploads of these packages were done?
[06:07] <carlos> kiko: since the migration to soyuz? yes
[06:07] <ddaa> kiko: I'll get a quick JS patch through you once I figured out how to do the initial sorting thing.
[06:07] <carlos> kiko: either that or that those packages miss the .pot file
[06:07] <kiko> ddaa, really? tell me about it
[06:07] <kiko> carlos, I will poke a distro person
[06:07] <ddaa> kiko: I will
[06:07] <carlos> kiko: please, don't do that is not needed
[06:08] <sabdfl> does an sqlresult evaluate to true if it has results?
[06:08] <carlos> I'm preparing a list of resources missing a .pot file
[06:08] <kiko> carlos, I just want to verify that is the case.
[06:08] <kiko> sabdfl, no.
[06:08] <carlos> and pitti is already aware of that and he's fixing them
[06:08] <kiko> sabdfl, you need to .count() it.
[06:08] <sabdfl> what's the canonical way to ... thanks :-)
[06:08] <kiko> sabdfl, actually, I'm wrong, since __nonzero__ now exists
[06:08] <salgado> no, you don't need to .count() it
[06:08] <carlos> kiko: let me study the output and fix anything we need to fix from our side before disturbing other people
[06:08] <kiko> sabdfl, it didn't exist before, but now it does. so reverting myself, yes.
[06:08] <carlos> kiko: as I said, it's a theory
[06:08] <carlos> not a fact
[06:08] <carlos> ;-)
[06:08] <carlos> I need to get a train, need to leave now.
[06:09] <sabdfl> ok, odd because tal:condition="foo" is not picking up the result even though there is one there
[06:09] <carlos> see you later
[06:09] <kiko> sabdfl, pdb it?
[06:09] <sabdfl> kiko: i did, that's how i realised there was actually a result in there
[06:09] <kiko> something wrong in your template most likely
[06:10] <sabdfl> i'm de-listifying, and of course it worked on a list
[06:10] <jordi> mdke_: hold on, will do it right now
[06:10] <sabdfl> did this change recently, might my sqlobject be out of date?
[06:10] <kiko> sabdfl, not recently.
[06:12] <sabdfl> is there an interaction between cachedproperty and sqlresults?
[06:13] <kiko> sabdfl, cachedproperty is dangerous if you are modifying the value in this request.
[06:13] <sabdfl> not modifying it, just querying at this stage
[06:14] <kiko> cachedproperty and sqlresults is silly, btw
[06:14] <kiko> because you are caching an object which holds no data
[06:14] <kiko> remember that the query is only issued when you /use/ the sqlresults
[06:14] <kiko> so if you want to cachedproperty you need to listify, sabdfl 
[06:15] <sabdfl> kiko: what if I cann a method twice, which returns an sqlresult with the same query
[06:15] <sabdfl> do i get the same sqlresult?
[06:15] <kiko> if it is cachedproperty, sabdfl?
[06:15] <sabdfl> no
[06:16] <kiko> then no.
[06:16] <kiko> but it doesn't matter
[06:16] <sabdfl> so, in this page i do a bunch of stuff IF i have matching results
[06:16] <sabdfl> so lots of condition="view/foo"
[06:16] <kiko> what is view/foo?
[06:16] <sabdfl> where view/foo is a function that calls a method on the context, which returns an sqlresult
[06:16] <sabdfl>     def speclinks(self):
[06:16] <sabdfl>         """Return the specification links with PROPOSED status this sprint.
[06:16] <sabdfl>         """
[06:16] <sabdfl>         speclinks = self.context.specificationLinks(
[06:16] <sabdfl>             status=SprintSpecificationStatus.PROPOSED)
[06:16] <kiko> you should cachedproperty the listified results in the view.
[06:17] <sabdfl> ok
[06:17] <sabdfl> oh fuck
[06:17] <sabdfl> blush
[06:17] <sabdfl> what will the above method return?
[06:17] <sabdfl> None. always
[06:17] <sabdfl> doh
[06:18] <kiko> it is a docstring bug, sabdfl!
[06:18] <jordi> mdke_: uh, I don't see it
[06:18] <jordi> is it in product series? (ie, not in the /distros/ubuntu tree)?
[06:18] <mdke_> jordi, it should be in the distribution.
[06:19] <mdke_> hang on
[06:19] <jordi> oh
[06:19] <jordi> ubuntu/desktopguide/desktopguide.pot in ubuntu-docs in Ubuntu Dapper ?
[06:19] <mdke_> jordi, https://lists.ubuntu.com/archives/dapper-changes/2006-April/008952.html
[06:19] <mdke_> jordi, that and others, yep
[06:19] <jordi> I see it
[06:19] <jordi> ok
[06:20] <mdke_> jordi, looks like the kubuntu one hasn't been uploaded yet
[06:21] <jordi> desktopguide, about-ubuntu, website-index, preface, packagingguide, serverguide
[06:21] <jordi> is that it?
[06:25] <jordi> mdke_: preface moved form installation-guide to ubuntu-docs?
[06:25] <mdke_> jordi, no, it's nothing to do with installation-guide
[06:26] <jordi> there's a potemplatename assigned to the instlalation-guide called preface already
[06:26] <mdke_> is that a problem?
[06:26] <jordi> https://launchpad.net/distros/ubuntu/dapper/+source/installation-guide/+pots/preface
[06:26] <mdke_> they are probably just different files which share the same name
[06:26] <jordi> Not sure. Probably not a problem, as this doesn't install .mo files, etc.
[06:27] <mdke_> right
[06:27] <mdke_> it's just for us
[06:27] <mdke_> it's a common file for each document
[06:27] <mdke_> i thought it would make sense to translate it once only
[06:28] <mdke_> (please refuse it if it appears in kubuntu-docs too)
[06:30] <salgado> kiko, how does https://chinstrap.ubuntu.com/~dsilvers/paste/fileu3YDzG.html looks like?
[06:30] <kiko> it looks like a fishing rod
[06:31] <salgado> but does it look like a plan? do you agree with these notifications being sent?
[06:32] <mdke_> notifications about group status? pleeeeeease
[06:32] <kiko> seems like in all cases you are sending notifications
[06:32] <kiko> mdke_, I promised, didn't I?
[06:32] <salgado> not really all
[06:32] <salgado> but most
[06:32] <kiko> salgado, only in the else clause not
[06:33] <kiko> salgado, all branches say they will send notifications
[06:33] <salgado> kiko, yes, but you can go from declined back to proposed, and I won't send in that case
[06:34] <salgado> on the other hand, if you go from declined to approved, then it will be sent
[06:34] <kiko> salgado, maybe use classes to indicate each of the cases?
[06:34] <kiko> that would be better I think
[06:35] <kiko> you can then use inheritance to simplify the code further
[06:35] <dilys> Merge to devel/launchpad/: [trivial]  Fix for bug #37053: Packages listed under Suggests in details have broken links. Fix dem links and add sampledata so somebody could actually notice what was going on (r3427: kiko)
[06:35] <kiko> y-a-y
[06:35] <jordi> mdke_: I suspect trying to use a unique name would help
[06:36] <jordi> but I don't think this will break
[06:36] <jordi> kiko: quick question: do you know if there are bad side effects with two source packages sharing a potemplatename?
[06:36] <salgado> kiko, I'm not following you
[06:36] <jordi> ie, installation-guide and ubuntu-docs both have a preface.pot.
[06:37] <kiko> jordi, there is no bad side effect I am pretty sure
[06:37] <kiko> I will move upstairs salgado 
[06:37] <jordi> kiko: k, approving
[06:37] <jordi> mdke_: should be done
[06:38] <mdke_> jordi, thanks
[06:43] <kiko> elmo, note stub's reply to us, you should be able to simplify your code.
[06:51] <ddaa> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/filev0a8fB.html
[06:51] <ddaa> I'm going to take a break, please dump your review comments here
[06:53] <ddaa> idle thougt: it would be much nicer to allow sorting by url argument, to support non-JS browsers
[06:54] <kiko> uhm
[06:54] <kiko> not trivial
[07:04] <BjornT> kiko: do yo still want me to review that patch?
[07:05] <dilys> Merge to devel/launchpad/: Fix https://launchpad.net/products/launchpad/+bug/37885 (Branch URL field doesn't properly validate input) r=ddaa (r3428: Diogo Matsubara)
[07:28] <ddaa> kiko: so, any review comments on that little JS trick?
[07:28] <ddaa> I'd really like to get it landed before sabdfl's branch so there is no regression
[07:29] <ddaa> Besides, I'd love to add a few JS gimmicks, like stable sorting and such.
[07:33] <dilys> Merge to devel/launchpad/: [trivial]  Fix for bug #37053: Packages listed under Suggests in details have broken links. Fix dem links and add sampledata so somebody could actually notice what was going on (r3429: kiko)
[07:40] <ddaa> yay, stable sorting done, too
[07:42] <ddaa> https://chinstrap.ubuntu.com/~dsilvers/paste/fileYIvCAe.html
[07:46] <ddaa> mh... not quite, sorry
[07:49] <ddaa> nevermind, it works :)
[07:49] <ddaa> Hey, somebody up to review some intense JS shyniness?
[07:50] <LarstiQ> just have a look, or actually reviewing it?
[07:51] <ddaa> review as in allow for landing on trunk, sorry LarstiQ, but your are not eligible :)
[07:51] <LarstiQ> thought so :)
[08:04] <bradb> Two hours later, the test suite finishes running, w00t.
[08:13] <tonyyarusso> Does anyone actually understand how Launchpad assigns karma?
[08:13] <ddaa> it's based on donations to carlos' paypal account ;)
[08:14] <tonyyarusso> Hehe.
[08:14] <bradb> If you sneeze on Rosetta, you get 18000 karma points.
[08:15] <ddaa> actually, it's a well defined algo and people know it, but I don't (and I do not care, anyway)
[08:15] <tonyyarusso> I ask b/c I don't understand mine.  I'm sitting at 10424, marked as soley in specifications, which I have suggested one of.
[08:15] <ddaa> basically, some actions are recorded and are associated some base karma
[08:15] <ddaa> and the karma for each actions decreases linearly over time to reach 0 after a year
[08:16] <tonyyarusso> Hmm.  Okay.
[08:18] <ddaa> looks like spec tracking is ridiculously overestimated
[08:18] <ddaa> maybe file a bug, on my account, my spec karma is 10x my bug karma, that's ridiculous
[08:19] <tonyyarusso> Maybe they're trying to encourage more ideas at the moment?
[08:19] <sabdfl> the aggregating algorithm is busted
[08:19] <ddaa> hell no
[08:19] <ddaa> we have no shortage of ideas
[08:19] <tonyyarusso> sabdfl: Aaah.
[08:19] <sabdfl> i think stub wants to assign the same "value" to "all the spec work in the system" and "all the bug work in the system"
[08:19] <sabdfl> so, if you did all the translating, and i did all the bug triage, we get the same score
[08:19] <tonyyarusso> ddaa: I thought that was probably the case.  Now we get the real answer :)
[08:20] <sabdfl> the underlying points are totally different from what you see
[08:20] <sabdfl> but since there are more ways to get points in the bug system, and more people using it, the value of each point is much less
[08:20] <tonyyarusso> sabdfl: So would that mean that if one category had very few submissions that each submission would be worth more points than each in another?
[08:20] <sabdfl> yes
[08:21] <tonyyarusso> Got it.
[08:21] <sabdfl> well, no
[08:21] <sabdfl> each POINT would be worth more
[08:21] <tonyyarusso> Okay, that one lost me.
[08:21] <sabdfl> in our system, each kind of submission gets a certain number of points
[08:21] <sabdfl> so, fixing a bug is different to reporting one, is different to marking it a dup
[08:21] <sabdfl> we can retune THAT balance whenever we want
[08:21] <sabdfl> that gives you a "total bug score" and a "total spec score"
[08:22] <sabdfl> then, i think there's a layer on top of that, which says:
[08:22] <sabdfl>  - in the ENTIRE system, the TOTAL bug score for ALL bug people is X
[08:22] <sabdfl>  - "  "   "   "   "   spec "  "  "  "  spec " " Y
[08:22] <sabdfl> then it normalises those two to be equal
[08:22] <sabdfl> and then it knows what one "bug point" is worth compared to one "spec point"
[08:23] <tonyyarusso> That makes more sense now.
[08:23] <sabdfl> i think there's a nice idea in there, which is to say that the real overall winners should be people that use the whole system
[08:23] <sabdfl> but the balance of the underlying points, and the overall aggregation algorithm, need work
[08:23] <sabdfl> plus, we need to be more sophisticated about the underlying karma points
[08:24] <tonyyarusso> It also encourages people to help out in areas that are underused, wouldnt it?
[08:24] <tonyyarusso> And more transparent, so people know what's going on underneath.
[08:24] <sabdfl> yes, it does encourage more use of less-used parts of the system
[08:25] <sabdfl> which is a good thing, for sure
[08:27] <bradb> kiko: Do you want to review the remove bpn patch? All tests pass, etc.
[08:27] <tonyyarusso> All right.  Well that was enlightening  :)
[08:28] <sabdfl> bradb: removing them from the bugtask headline?
[08:29] <bradb> sabdfl: removing bpn from Malone, IBugTask, etc. (so, yes, the headline too)
[08:29] <bradb> s/headline/header/
[08:29] <sabdfl> bradb: do you know what the intent of the bpn was, there?
[08:33] <bradb> er, you mean in X-Launchpad-Bug? come to think of it, I'm not sure if it was part of that header or not.
[08:34] <bradb> It seems mainly to annoy maintainers on +editstatus, so it would have been even less useful in the header, I think.
[08:36] <bradb> yeah, it wasn't ever in X-L-B, as best I can tell
[08:40] <sabdfl> i mean, what the purpose of the binary package name field in bugtask was
[08:43] <bradb> ah. I think it was a case of not having enough information about the use cases to realize how much of a burden it would become. it was clear that the user should be able to specify a bpn when filing, but less clear that storing bpn and making it editable on the status page would be a burden to devs.
[08:44] <tonyyarusso> Another (somewhat silly) question:  I misclicked one day and registered my spec for the fosdem sprint.  I don't even really know what that is, and have no idea if it's appropriate for it to have that flag on it, but don't know how to undo that.
[08:45] <tonyyarusso> Or is it to late already and it doesn't even matter?
[08:46] <sabdfl> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dpkg-dev
[08:46] <sabdfl> bradb: ^
[08:46] <tonyyarusso> (spec in question is livecd-apt-install-to-usbflash)
[08:46] <sabdfl> debian dev like to organise bugs by binary package
[08:46] <sabdfl> within a source package
[08:46] <sabdfl> the fundamental unit is the source package
[08:47] <sabdfl> the binary package is kind of a nice way to group the bugs
[08:47] <sabdfl> terminating it is no major loss to me
[08:47] <sabdfl> but you should understand what the DD's want before you do that
[08:47] <bradb> as a data point, mdz says there's been about twice that bpn information was useful to him
[08:47] <sabdfl> ask them if they want to see listings of bugs on a source package, grouped by binary package
[08:48] <sabdfl> the data is only there because folks used to debbugs said "i have to have that"
[08:48] <sabdfl> personally, i don't care
[08:48] <sabdfl> but don't use the argument of someone who is looking at a broken implementation of a good idea as an excuse for not understanding the original idea
[08:48] <sabdfl> 'k?
[08:49] <bradb> ok
[08:50] <bradb> maybe I'll mail ubuntu-devel, just to be sure
[08:52] <sabdfl> take a look at debbugs
[08:52] <sabdfl> personally, i'm no fan of the feature
[08:52] <sabdfl> i definitely think the current implementation is all work no play
[08:53] <sabdfl> but i don't want stuff thrown out when it clearly hasn't been grokk'ed in the first place
[08:54] <bradb> i'm aware of listing bugs by binary package, but there are at least two reasons it has never taken off: 1. nobody every requested it, or spoke of their workflow in a way to suggest such functionality could make their life easier and 2. bpn data is often wrong, and pretty difficult to keep accurate without burdening devs to maintain it
[08:55] <bradb> s/wrong/missing or wrong/
[09:10] <sabdfl> bradb: i agree
[09:21] <Burgwork> bradb, why is binary package information often wrong?
[09:24] <bradb> Burgwork: Because the bug may have been reported on the wrong SP, get reassigned to a new one, and still have the old BP information.
[09:24] <bradb> Or, of course, the user might have just provided the wrong BP.
[09:26] <Burgwork> bradb, I consider that a bug
[09:26] <Burgwork> users think in binary package terms
[09:26] <bradb> Burgwork: Indeed, that's why +filebug will continue to accept a BP
[09:27] <Burgwork> then you have a bait and switch issue
[09:27] <Burgwork> you get them to file under something and it shows up as something else
[09:27] <bradb> yeah, but we can use feedback messages to solve that
[09:28] <Burgwork> umm, not really
[09:28] <Burgwork> to me, this looks like an ingrown toenail, so to fix it we are going to take the leg off
[09:29] <kiko> there is the alternative of nullifying the binary package when the source package gets set
[09:31] <bradb> yeah, so that BP will be less wrong and more missing
[09:32] <bradb> Burgwork: how do you think it should work?
[09:33] <mdz> Burgwork: yes, users do, so we should allow them to file a bug against a binary package and have it automatically directed to the corresponding sourc epackage
[09:34] <Burgwork> however, not being able to search on binary package is an issue
[09:34] <Burgwork> because a midly technical user might know to search, only know the binary name and return nothing
[09:34] <mdz> sure, it's reasonable to expect to be able to look up the bugs by binary->source mapping as well
[09:35] <Burgwork> as long as a search for a binary package name returns what it should, that is ok
[09:39] <kiko> BjornT?
[09:39] <salgado> kiko!
[09:39] <kiko> hey salgado 
[09:39] <kiko> what now?
[09:40] <BjornT> kiko: yes? i'm here
[09:40] <kiko> y-a-y
[09:40] <kiko> BjornT, review my patch for your bug!
[09:40] <salgado> I guess we need to send different emails for the admins and to the member that's being approved/whatever
[09:41] <kiko> the templates should be slightly different, you mean?
[09:41] <kiko> BjornT, https://chinstrap.warthogs.hbd.com/~dsilvers/paste/filelcEchA.html
[09:41] <salgado> kiko, yes
[09:41] <kiko> BjornT, it is a gift for you
[09:41] <kiko> salgado, yes, I agree
[09:41] <BjornT> kiko: sure, i can review it now
[09:41] <kiko> because of the language "Your request" versus "The request from %s", salgado?
[09:41] <salgado> that makes things a bit more complex
[09:42] <kiko> mmmm, perhaps.
[09:42] <salgado> if we can manage to get a template where the only difference is that... that would be perfect
[09:45] <kiko> BjornT, rock and roll!
[09:46] <bradb> Burgwork: fwiw, I think mapping BP to SP in an SQL query is a much more accurate and effective way to search on BP, than relying on the BP we sometimes have available on a bug
[09:47] <kiko> agreed
[09:47] <kiko> the /only/ thing the BP is useful for is indicating in what area of the SP the bug is
[09:48] <kiko> but that appears to be a very weak link
[09:53] <sabdfl> bradb: mapping BP to SP is very tricky
[09:53] <sabdfl> because it depends totally on the DistroArchRelease
[09:53] <sabdfl> it can be different in different releases, or on the same release in different arch's
[09:53] <bradb> yeah, I've experienced that pain :)
[09:54] <sabdfl> very tricky indeed
[09:54] <sabdfl> it's not rigorous, and BugTask does not contain enough data to make it rigorous
[09:54] <sabdfl> and getting it to contain that data would make it unuseable
[09:54] <sabdfl> so...
[09:54] <Burgwork> bradb, sure that works
[10:12] <LaserJock> bradb: ping?
[10:12] <bradb> LaserJock: pong
[10:13] <LaserJock> bradb: I was just reading your -devel email. Does that mean that bug reporters need to know the source package name?
[10:13] <kiko> no it doesn't
[10:13] <kiko> perhaps bradb should follow up to that email clarifying
[10:13] <bradb> LaserJock: Nope. As noted in the email, +filebug will still accept a BP.
[10:14] <elmo> bradb: but people trying to file bugs and searching for duplicates before filing will be listing/searching by BP, most of the time?
[10:14] <LaserJock> elmo: that was my concern
[10:16] <bradb> elmo: They can't list by BP as it is. The search can be made to work without storing BP on the bug. (In fact, it would work a whole lot better if a proper SQL query mapped the BP to the SP, rather than counting on the BP we recorded, which will often be empty or wrong.)
[10:16] <kiko> elmo, that doesn't work today regardless, and I don't think reporter-included information is a good guide to that
[10:16] <kiko> basically what bradb said
[10:16] <elmo> right, I realise it doesn't work today and it's one of the things that makes malone most painful to use IMHO
[10:17] <kiko> ok
[10:17] <elmo> I've got a bug on linux-image-2.6.15-whatever, I don't want to have to jump through the click hoops necessary to figure out which source package that came from to check pre-existing bugs
[10:18] <kiko> okay
[10:18] <bradb> I can appreciate that. I'm just saying that you'd get much better results if we didn't store BP on the bug.
[10:18] <elmo> (http://bugs.lp.net/<binarypkg> would be even better, but that's another story ;-)
[10:18] <kiko> bradb, we could convert this in run-time
[10:19] <bradb> yeah
[10:19] <kiko> using the same algo we use to detect the SP
[10:19] <kiko> given that I think that dropping the BP and doing this sounds like the most reasonable plan
[10:19] <bradb> yep. the URL would list all bugs on the SP for that BP, is that what you're thinking?
[10:20] <kiko> oh, a URL?
[10:20] <kiko> I wasn't thinking of that, but I guess
[10:20] <ddaa> kiko: would you be kind enough to review david/launchpad/sorttable?
[10:20] <bradb> well, we /could/ have it possible, but otherwise just as search criteria too
[10:20] <kiko> ddaa, I don't want the a.oldPosition - b.oldPosition
[10:20] <ddaa> that's what does stable sorting...
[10:20] <ddaa> well, it was a bit buggy, fixed now
[10:20] <kiko> well, find another way of doing it
[10:21] <kiko> keep the ts_sort_* methods as simple as possible
[10:21] <kiko> doable?
[10:21] <LaserJock> bradb: anyway, I'm all for your proposal. I was just concerned about users having to know the BP->SP mapping.
[10:21] <bradb> I'm going to followup to u-d with some more information/clarification
[10:22] <ddaa> I do not think there's any other good way, the sorting is done with Array.sort(). Short of reimplementing that (which would be a bad idea IMO) we have to put the smarts in the comparison methods.
[10:22] <kiko> ddaa, I see. mmmm.
[10:23] <kiko> is JS sort not stable by default? they need timsort
[10:23] <ddaa> kiko: obviously, it is not
[10:23] <ddaa> as a rule, JS sucks by default
[10:24] <kiko> I have an idea!
[10:24] <kiko> why don't you define a ts_cmp() method
[10:24] <kiko> to which you provide aa and bb?
[10:24] <kiko> return ts_cmp(aa, bb)
[10:24] <kiko> would be at the end of all sorting functions 
[10:24] <kiko> instead of the comparison
[10:24] <ddaa> Mh.
[10:24] <kiko> would that work I wonder
[10:24] <mdke> jordi, kubuntu-docs is uploaded, I'm told
[10:24] <ddaa> What I can do is layer the stable sorting bit
[10:24] <salgado> kiko, what do you think of a template like https://chinstrap.ubuntu.com/~dsilvers/paste/fileaFbJYw.html, to start with?
[10:25] <ddaa> kiko: using a closure
[10:25] <kiko> salgado, looks generic enough. the thing about "from %s to %s" sounds like computerese but I understand why you want it
[10:25] <ddaa> I heard that JS closures do not suck too much. I'll give it a try.
[10:25] <kiko> ddaa, k
[10:26] <salgado> kiko, or something similar where we only need to change the first line while sending them to team admins
[10:26] <kiko> salgado, perhaps it is better not to disclose who made the change
[10:26] <kiko> that way it is not a personal decision
[10:26] <kiko> but a team decision
[10:26] <kiko> the admins should know who made the change howevever
[10:27] <salgado> yeah, it makes sense
[10:27] <kiko> sorry for complicating
[10:27] <mdke> jordi, also, do you get to delete stuff, or is carlos the only one? I will wait until they are removed before announcing translations because I don't want people wasting more time translating useless stuff
[10:27] <salgado> it's no big deal, actually
[10:46] <sabdfl> night all
[10:48] <kiko> BjornT, does it make sense to document __init__ in an interface docstring?
[10:48] <kiko> how is that done?
[10:48] <kiko> or salgado 
[10:49] <ddaa> __init__ methods are module functions as far as interfaces are concerned
[10:50] <ddaa> I think the old pyarch interface had some of that stuff.
[10:51] <ddaa> Something like Froboizer = Attribute("Create a IFroboizer")
[10:51] <ddaa> well not quite
[10:51] <ddaa> def Froboizer(arg1, arg2):
[10:51] <ddaa>     """Create a IFroboizer"""
[10:51] <BjornT> kiko: why do you want to do that? it gets kind of awkward since the corresponding method in an interface would be __call__
[10:52] <kiko> BjornT, I want to document the constructor
[10:52] <BjornT> kiko: and it doesn't make sense to document it in the class only?
[10:53] <kiko> BjornT, it's weird to have half the documentation in the interface and half in the class. and it is a property of the interface, the constructor!
[10:57] <ddaa> Actually, when you think about it, the constructor is effectively a property of the module containing the class.
[10:57] <kiko> yeah. the only reason we don't document our database classes' __init__ is because it doesn't really exist as such :)
[10:58] <ddaa> i.e. module.Class is factory method that creates instances of module.Class
[10:58] <ddaa> obviously module.Class would be a method of module if Python was Smalltalk.p
[11:02] <BjornT> kiko: i'd say listen to ddaa. an interface documents the public api of objects providing the interface. if a class implements an interface, it most of the time doesn't provide the interface, instances of the class do though.
[11:02] <BjornT> kiko: so a class' __init__ isn't a part of the public api
[11:03] <ddaa> What BjornT says with the proper terminology.
[11:03] <kiko> BjornT, so what do I do?
[11:03] <BjornT> kiko: document the method in the class?
[11:04] <kiko> ok then.
[11:04] <kiko> it keeps documentation in two separate /files/
[11:04] <kiko> but I will do it because you said so (and because it allows me to go on working)
[11:05] <BjornT> kiko: well, you could create a new interface if you wanted ;)
[11:05] <ddaa> kiko: you liking that better? https://chinstrap.ubuntu.com/~dsilvers/paste/fileYexDjG.html
[11:06] <seb128> bradb: who said that binary packages are useful (just curious about it)?
[11:07] <bradb> seb128: elmo, for searching. Burgwork, probably others.
[11:07] <seb128> Burgwork: ping? what is the use of binary package for you?
[11:07] <seb128> bradb: ta
[11:08] <BjornT> kiko: for example, if you look at vocabularies, you'll find that vocabulary classes provide IVocabularyFactory (which has a __call__ method). i'm not suggestion you should do that though.
[11:10] <Burgwork> seb128, I am more thinking of users who maybe don't know the difference and are trying to get into bug filing/triage
[11:11] <seb128> bug filing understood them
[11:11] <seb128> understand
[11:11] <kiko> ddaa, ah, that is much better
[11:11] <seb128> Burgwork: if you don't know what a source package is you might not be qualified to reassign bugs to an another package
[11:11] <seb128> Burgwork: without any offense
[11:12] <ddaa> kiko: I need to "var cmp = sortfn(a, b)", but besides, do you want any other change before I can r=kiko?
[11:12] <Burgwork> seb128, I know, but there are others that do not
[11:12] <seb128> if we discourage people who don't know what a source package is to reassing that's rather a feature :p
[11:12] <Burgwork> seb128, here is my usecase: somebody knows how to file a bug and whats to be a good citizen and look for dups. So they search for the binary name. Need to get useful results
[11:13] <seb128> you put a binary, it should convert that to source package for you
[11:13] <seb128> like when you file bug
[11:13] <kiko> Burgwork, that is orthogonal to allowing the user to specify the binary package.
[11:13] <seb128> you don't need to care as an user
[11:13] <kiko> is that part clear?
[11:13] <Burgwork> yes
[11:13] <seb128> that should be transparent for the user
[11:13] <kiko> right
[11:14] <Burgwork> I believe that bradb has already answered my objection
[11:14] <kiko> ddaa, can you avoid needing ts_firstChildByName() by changing the resortTable API slightly?
[11:14] <seb128> yeah, but he said to the same mail on the list that you argue to have a binary package option
[11:14] <ddaa> kiko: nope, the ts_resortTable API is dictated by onclick="ts_resortTable(this); return false;"
[11:15] <kiko> ddaa, change that.
[11:15] <Burgwork> no, he said I was concerned about how a user can find other bugs, based simply on the information of knowing what binary package it was in
[11:15] <seb128> "Some users have suggested that searching by binary package is really important"
[11:15] <kiko> ddaa, or make another method that ts_resortTable() calls
[11:15] <Burgwork> yes
[11:15] <seb128> there is a different between searching by binary
[11:15] <kiko> that doesn't require something as arbitrary as a link
[11:15] <seb128> and mapping to source for the query
[11:15] <Burgwork> we are talking about the same thing seb128 
[11:16] <seb128> in one case you argue that having to make the different between bugs applying to gedit and gedit-common makes a difference
[11:16] <seb128> not clear by reading the mail
[11:16] <Burgwork> ok
[11:16] <seb128> you could are that gedit-common query should no list gedit-bin bugs by example
[11:16] <ddaa> kiko: well, I could make it onclick="ts_resortTable(getParent(this, 'td'))"
[11:16] <seb128> or say that a gedit-common bugs should list all the gedit source package bugs rather
[11:16] <Burgwork> anyway, the mapping looks good
[11:16] <Burgwork> we can work on specific UI issues later
[11:17] <seb128> fine with me
[11:17] <kiko> ddaa, would that be less code?
[11:18] <ddaa> not sure, actually ts_firstChildByName() could be used to remove some other code...
[11:18] <ddaa> but I wanted to avoid gratuitous refactorings
[11:19] <kiko> I'd do it if you think it works, otherwise getParent() looks more attractive.
[11:20] <ddaa> well, it means I'll have to duplicate the firstChildByName logic in ts_resortTable where it looks for img.
[11:21] <kiko> you're right.
[11:22] <ddaa> but I _can_ refactor that bit to use ts_firstChildByName :)
[11:22] <kiko> sounds good
[11:22] <kiko> do it, and let me see the patch
[11:29] <ddaa> kiko: do you mean change the ts_resortTable API, or just factor out some code using ts_firstChildByName?
[11:30] <kiko> ddaa, factore the code out
[11:31] <ddaa> bzr tip of the day
[11:31] <ddaa> when in a light checkout
[11:31] <ddaa> echo -n ~/path/to/branch > .bzr/branch/location ; bzr update
[11:31] <ddaa> effectively implements "bzr switch" functionality
[11:32] <ddaa> the -n option is important
[11:47] <kiko> fix build bustage. fix build bustage. fix build bustage.
[11:47] <tseng> kiko-buildbot?
[11:47] <kiko> no, kiko-hyatt-mode