[12:12] <kiko> matsubara, vai ou no vai? eu tenho que ir embora!
[12:13] <matsubara> vou onde?
[12:53] <X1n3> hi
[12:56] <X1n3> what is?
[12:56] <X1n3> that the free cds need to be aproved?
[12:57] <X1n3> i have 45 of the 100 that i say
[12:58] <kiko> X1n3, write to the email address I provided earlier.
[01:08] <ryanakca> what is "ubuntero"?
[01:10] <kiko> another FAQ
[01:10] <kiko> a person who has signed the Code of Conduct
[01:13] <ryanakca> kk, ty
[01:13] <kiko> njy
[01:18] <kiko-zzz> dilys, give me the good news tomorrow
[01:25] <dilys> Merge to devel/launchpad/: [trivial]  Fix for bug 31380: source package sort by version doesn't cope with invalid version numbers. Use apt_pkg.VersionCompare instead of Sourcerer's unmaintained Version method which blows up occasionally. Fixes an OOPS. Even removes an XXX (r3192: kiko)
[02:04] <dilys> Merge to devel/launchpad/: rs=BjornT though rather trivial; Fix for bug 31367: Specifying a non-published binary package when filing a bug causes an oops. Change the add bug process to ignore the package if it was never published in the distribution, and test it using Gentoo (which now uses Malone officially, yay. Or at least in sampledata). This fixes a topcrasher, so hooray for us. (r3193: kiko)
[02:13] <Kinnison> jamesh: ping?
[02:23] <jamesh> Kinnison: pong
[02:23] <Kinnison> jamesh: I'm desperate for a bzr conversion of the gnome-power-manager portion of gnome-cvs
[02:23] <Kinnison> jamesh: but tailor can't do its job from gnome anoncvs
[02:23] <Kinnison> jamesh: any chance you could grab me a tarball of that bit of cvs?
[02:23] <jamesh> you want a tarball of the repo?
[02:23] <Kinnison> please
[02:24] <Kinnison> it's 01:24
[02:25] <jamesh> http://www.gnome.org/~jamesh/gnome-power-manager-repo.tar.gz <- 3.8MB
[02:25] <Kinnison> fetching now
[02:26] <jamesh> Kinnison: looks like time doesn't go backwards for that module, so Tailor shouldn't get confused
[02:27] <Kinnison> UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-3: invalid data
[02:27] <Kinnison> go tailor
[02:31] <Kinnison> any suggestions?
[02:32] <Kinnison> if I do "LANG=C ....." then it whinges the equivalent with an ascii codec
[02:33] <stub> Might try LANG=en.iso-8859-1  -- text files without an explicit encoding have a tendancy to be iso-8859-1 encoded
[02:34] <Kinnison> that's an "unsupported locale" apparently
[02:35] <Kinnison> even after I've allegedly created the en_GB.ISO8859 locale python rants
[02:36] <stub> Kinnison: You could try changing the default encoding in /usr/lib/python2.4/site.py (the setencoding() method), but make sure you change it back!
[02:37] <jamesh> Kinnison: did you try putting "encoding = iso-8859-1" in the [cvs:source]  section of your .tailor file?
[02:38] <Kinnison> nope 'cos I didn't know it existed
[02:38] <Kinnison> trying
[02:38] <Kinnison> oooh, jamesh wins
[02:38] <Kinnison> tailor running
[02:38] <jamesh> iirc, tailor told me to do that when I tried
[02:38] <Kinnison> jamesh: aah didn't tell me
[02:38] <jamesh> Kinnison: which version of tailor are you using?
[02:39] <Kinnison> 0.9.20 apparently
[02:39] <jamesh> Tailor could certainly do with some robustness improvements
[02:40] <stub> Anyone have access to merge to the tailor trunk? pull out canonical.encoding and use encoding.guess as a fallback. Otherwise you won't be able to migrate trees where commit messages used mixed encodings.
[02:52] <Kinnison> <voice style="gump">Run tailor! Run!</voice>
[03:29] <Kinnison> Hmm, up to the 19th January
[03:35] <Kinnison> cor 10th Feb
[03:35] <Kinnison> tailor in getting faster shocker
[03:42] <Kinnison> jamesh: you're a star
[03:42] <Kinnison> ciau
[05:16] <jamesh> stu1: do you have any ideas about this bug? https://launchpad.net/products/launchpad/+bug/31651
[05:16] <Ubugtu> malone bug 31651 in launchpad "IPlacelessLoginSource.getPrincipalByLogin(email) returns None with an email address that was just created" [Normal,Confirmed]  
[05:17] <jamesh> stub: the second OOPS report seems very weird, given the statement log
[05:22] <stub> If the insert was failing, the transaction would be screwed. So we can assume the inserts are working correctly
[05:22] <stub> I could see that behavior happening if we had multiple connection objects.
[05:23] <stub> I could see that happening if some of the code was creating a connection using sqlbase.connect(), as it opens a fresh database connection.
[05:24] <stub> (by default - I think I landed an option recently to make that call reuse the existing connection if a parameter is passed? Can't remember if it landed or if I backed it out)
[05:24] <stub> But that wouldn't be happening because it is all SQLObject code
[05:25] <jamesh> could it be index corruption?
[05:26] <stub> Unlikely - postgresql is good on that front. Bugs like that seem to only occur in the pathalogical edge cases some people create.
[05:26] <stub> But possible
[05:27] <stub> Do we log calls to the connections commit and rollback methods?
[05:28] <stub> Easiest way to explain that behavior would be some doofus sticking a rollback in the code, or rollback being called by Z3 for some pathalogical reason
[05:30] <stub> Is it happening often? I  can reindex the person table for a laugh but it will render launchpad unusable for maybe 10 mins
[05:31] <jamesh> I don't know how often it happens: salgado only mentioned two oops reports
[05:31] <stub> I'll make a note to reindex the person and emailaddress tables next rollout (and hopefully remember to check my notes...)
[05:41] <jamesh> I wonder how much more reliable things would be if SQLObject did "self._connection = self._connection" in its constructor?
[05:41] <jamesh> it'd definitely help with problems related to garbage collection on the wrong thread
[05:53] <stub> SQLOS replaces self._connection with a descriptor, so in our case I don't think it would help much (?).
[06:03] <jamesh> the descriptor is the issue: it means that if an object gets garbage collected on a different thread, the destructor will use a different _connection than the one used to create the object
[06:04] <jamesh> so the object doesn't get removed from the cache
[06:06] <spiv> jamesh: Ouch, that's a nasty one.
[06:06] <jamesh> spiv: SteveA pointed it out to me originally
[06:06] <spiv> jamesh: Yeah, instances really should know what connection they're tied too.
[06:07] <jamesh> spiv: with plain sqlobject they do: self._connection :)
[06:07] <spiv> Right :)
[06:07] <spiv> zopeless also has its own descriptor for _connection :/
[06:08] <jamesh> yeah
[06:08] <jamesh> I suppose one way to do it would be to make the descriptor's __get__ method do the assignment
[06:08] <jamesh> so an sqlobject gets bound to a connection the first time it tries to use it
[09:15] <istbot> hi 
[09:16] <istbot> fuck you ChanServ
[11:21] <carlos> spiv: hi, around?
[11:24] <ddaa> lifeless: can you make it more apparent, in emails sent to arch-commits, what is the branch being merged into?
[11:25] <ddaa> For example, by telling the branch name and nick in the message body and in a header
[11:25] <ddaa> I'm quite confused with bzr commits being mixed with launchpad commits
[11:26] <ddaa> I have to actually think to tell what the commit is relevant to.
[11:26] <ddaa> It hurts.
[11:41] <stub> +1
[11:43] <mpt> And also list the commits in chronological instead of reverse chronological order :-)
[11:43] <mpt> And make the list of modified files as compact as it was in the baz days
[11:43] <mpt> And, and, and ...
[11:44] <mpt> carlos, do you happen to know what the template equivalent of 'launchpad.Edit' is?
[11:44] <mpt> tal:condition="..."
[11:45] <mpt> I thought it would be tal:condition="view/edit", but no
[11:45] <carlos> I don't remember it, but I know where I can see it
[11:45] <carlos> just a second...
[11:46] <carlos> mpt: well, you first need to associate the launchpad.Edit permission with the interface
[11:46] <mpt> I think it already is, because it's used for this page's menu
[11:46] <mpt> s
[11:47] <mpt> @enabled_with_permission('launchpad.Edit') works for one of the menu items
[11:47] <mpt> but now I want to do the same thing in TAL
[11:48] <mpt> hmmm, other templates are using "view/edit"
[11:48] <carlos> tal:condition="entry/required:launchpad.Edit"
[11:49] <carlos> entry is a SQLObject
[11:50] <mpt> aha
[11:50] <mpt> so in this case, tal:condition="context/required:launchpad.Edit"
[11:50] <mpt> Great, carlos, thanks
[11:50] <carlos> yeah
[11:50] <carlos> mpt: you are welcome
[11:52] <mpt> another bug fixed
[12:00] <mpt> and another
[12:02] <hunger> Is there any documentation on what I should do to report bugs in launchpad?
[12:03] <hunger> Like should I assign bugs? To whom? May I close bugs? Which ones? Which priorities/severities may I assign? That kind of stuff?
[12:04] <hunger> What does assigning a bug signify?
[12:04] <hunger> All this workflow kind of stuff.
[12:11] <BjornT> hunger: that kind of workflow is specific to each project using launchpad. for example for ubuntu bugs, http://www.ubuntu.com/community/participate#head-5f51744fe2ab198ea488499b475eedefb45860c2 is proably a good start.
[12:11] <hunger> BjornT: Thanks!
[12:13] <hunger> Even though the documentation is still about bugzilla there:-)
[12:14] <cprov> good morning 
[12:16] <BjornT> hunger: really? :) i looked only briefly, and saw that it mentioned launchpad and malone, so i assumed they were updated
[12:53] <kiko-zzz> hello hackers of the world
[12:53] <kiko-zzz> UNITE
[01:04] <kiko> stub, ping?
[01:17] <stub> kiko: pong
[01:17] <kiko> hello stub 
[01:17] <kiko> how's thailand today?
[01:17] <kiko> it is hot and humid here
[01:17] <kiko> and the air is sizzling with pqm commits
[01:18] <stub> kiko: same same
[01:18] <kiko> stub, would you consider my commits from yesterday for the rollout?
[01:18] <stub> yes, I was thinking of rolling out...
[01:18] <stub> r3193
[01:18] <kiko> stub, matsubara has one OOPS fix to land this morning
[01:19] <stub> ok
[01:19] <kiko> it hasn't landed because he apparently hasn't had a haircut yet or something like that
[01:19] <kiko> matsubara, can you mail stub cc: launchpad with the revision you land your majestic fix for bug 5757 the bug from hell?
[01:19] <Ubugtu> malone bug 5757 in malone "OOPS: requesting an upstream fix doesn't check input for duplicates" [Normal,In progress]  http://launchpad.net/bugs/5757
[01:19] <stub> Can I use that excuse?
[01:20] <kiko> stub, it's harder in your case because it is painfully obvious you have not had a haircut in the last 19 years
[01:20] <matsubara> kiko: yes, I can. but let's see if pqm will accept it
[01:20] <kiko> thanks
[01:21] <matsubara> kiko: 4 conflicts
[01:21] <kiko> fix them and resubmit
[01:21] <kiko> they should be trivial
[01:22] <ddaa> does the zopeless test harness actually commit to the database?
[01:22] <kiko> daf, ping?
[01:22] <kiko> ddaa, I believe so
[01:22] <kiko> otherwise, how would selects work?
[01:22] <ddaa> i.e. if I use LaunchpadZopelessTestSetup, can I put some some test data in the database, spawn a subprocess, and have the subprocess retrieve the data?
[01:23] <lifeless> yes
[01:23] <ddaa> (after commit, of course)
[01:23] <kiko> yes
[01:23] <kiko> ddaa, look at gina.txt
[01:23] <kiko> I do something like that in it
[01:23] <ddaa> I trust you.
[01:23] <kiko> there may be hints in that file
[01:24] <ddaa> just starting to hit the first "duh, didn't think of that" in implementing bzr imports...
[01:24] <kiko> stub, ping 2.0, a bit more urgent
[01:24] <kiko> https://launchpad.net/distros/ubuntu/+ticket/256/+index\
[01:24] <ddaa> okay, looking
[01:24] <kiko> stub, this suggests to me that the migration for statuses we did wasn't complete
[01:24] <kiko> stub, can you handle the database hack?
[01:25] <stub> ok
[01:26] <ddaa> kiko: it's the first time I see a use of "import transaction". Is that a relic, or is that a new preferred way of doing commits and stuff?
[01:26] <kiko> I think it's the way it's done in tests BIMBW
[01:28] <ddaa> how does that compare to canonical.database.sqlbase's begin, commit and rollback?
[01:28] <stub> launchpad_prod=# select status,count(*) from ticket group by status;
[01:28] <stub>  status | count
[01:28] <stub> --------+-------
[01:28] <stub>      30 |    12
[01:28] <stub>      20 |   169
[01:28] <stub>      10 |   222
[01:28] <stub> (3 rows)
[01:29] <kiko> stub, wth is wrong with that page? is it a keyerror on something else? it still oopses
[01:29] <stub> The ticket update has been done - not sure where that 40 is comming from?
[01:29] <kiko> could it be /gasp/ hardcoded?!
[01:29] <stub> Would the page template be broken?
[01:30] <kiko> it must be the case
[01:30] <kiko> probably something wrong in the menu links
[01:30] <kiko> but where?
[01:31] <kiko> stub, can you make sense of that traceback?
[01:32] <BjornT> kiko: ah, i think there is some history that needs to be migrated :(, i'll take a look.
[01:32] <kiko> thanks BjornT 
[01:33] <kiko> that's okay -- it appears to be affecting few users
[01:34] <BjornT> stub: please run: select status,count(*) from ticketreopening group by status;
[01:35] <stub> Just found that table :)
[01:35] <kiko> launchpad_staging=> select priorstate,count(*) from ticketreopening group by priorstate;
[01:35] <kiko>  priorstate | count 
[01:35] <kiko> ------------+-------
[01:35] <kiko>          30 |    23
[01:35] <kiko>          50 |     2
[01:35] <kiko>          40 |     3
[01:35] <kiko> (3 rows)
[01:35] <kiko> enjoy the pain
[01:36] <kiko> man this my bloody valentine album is excellent
[01:38] <stub> BjornT: Do you think just priorstate needs to be updated, or is it more complex like the ticket update patch?
[01:39] <stub> Otherwise I've got:
[01:39] <stub> UPDATE ticketreopening SET priorstatus=10 WHERE status IN (20, 30);
[01:39] <stub> UPDATE ticketreopening SET priorstatus=20 WHERE status=40;
[01:39] <stub> UPDATE ticketreopening SET priorstatus=30 WHERE status=50;
[01:41] <BjornT> stub: it's just the priorstate column that needs to be updated. yes, i was going to give you those queries :) although, the last 'status's should be priorstatus as well.
[01:41] <kiko> BjornT?
[01:41] <BjornT> kiko: yes?
[01:41] <kiko> I didn't understand your last phrase.
[01:41] <stub> bah - they are all priorstate
[01:42] <kiko> ah, yes.
[01:42] <stub> tickets fixed
[01:42] <kiko> good work stub and BjornT 
[01:42] <kiko> the page works!
[01:50] <kiko> stub, ping?
[01:50] <stub> ?
[01:51] <kiko> stub, could you find out how many bugwatches we have for each bug tracker type?
[01:51] <kiko> I'm in the middle of a hack or else I would do it myself
[01:51] <kiko> if you are uberbusy I can do it later
[01:54] <stub> launchpad_prod=# select count(*),bugtrackertype from bugtracker,bugwatch where bugwatch.bugtracker = bugtracker.id group by bugtrackertype;
[01:54] <stub>  count | bugtrackertype
[01:54] <stub> -------+----------------
[01:54] <stub>   3730 |              2
[01:54] <stub>  22965 |              1
[01:54] <stub>      9 |              4
[01:54] <stub> (3 rows)
[01:54] <kiko> thanks dude
[01:54] <kiko> appreciated
[01:56] <carlos> If you need me for anything, I will be available by phone. I need to recharge it
[01:56] <carlos> see you later
[01:56] <kiko> carlos, did you get cprov a bugfix
[01:56] <kiko> shit
[02:08] <salgado> stub, can you do a select datecreated from person where name = 'daniangella'; on production?
[02:08] <stub>  2006-02-23 10:20:46.878019
[02:09] <salgado> that's UTC, right?
[02:11] <stub> yup
[02:33] <kiko> BjornT, ping?
[02:33] <kiko> bradb, ping?
[02:34] <bradb> kiko: pong
[02:34] <kiko> bradb, have we had the existing Ubuntu Dapper tasks closed or updated?
[02:34] <kiko> bradb, if not, could you please take care of that today.
[02:35] <bradb> sure
[02:35] <kiko> (mark mailed me) thanks!
[02:36] <bradb> Hm, this could be painful
[02:36] <bradb> There are 49 + assignee and various status information to keep on them.
[02:37] <kiko> I wonder if we can offload that to someone else.
[02:37] <kiko> jblack?
[02:39] <bradb> Maybe an Ubuntu triager?
[02:39] <kiko> can you try finding one?
[02:39] <bradb> sure
[02:43] <jblack> kiko:?
[02:43] <kiko> jblack, was wondering if you could help us with something, but..
[02:43] <jblack> but... 
[02:44] <jblack> what's the something?
[02:44] <kiko> moving some ubuntu bugs around 
[02:44] <kiko> let's see if dholbach is game first, otherwise you can help
[02:44] <jblack> heh. I don't know if I can help until I understand the scope of the help.
[02:45] <kiko> :)
[02:45] <jblack> If its a company priority, I can drop work responsibilities to do it though.
[02:47] <bradb> jblack: looks like dholbach is on top of it, thanks
[02:52] <BjornT> kiko: pong?
[02:52] <kiko> BjornT, never mind, was the topic above
[02:52] <BjornT> ok
[02:52] <kiko> thanks though
[03:01] <mdke_> hi all
[03:01] <kiko> hello mdke_ 
[03:01] <mdke_> an upload to breezy-updates was published yesterday
[03:01] <mdke_> and it has appeared in the archive but is not being included in the index
[03:01] <mdke_> https://launchpad.net/distros/ubuntu/breezy/+source/ubuntu-docs/5.10-6.3
[03:01] <mdke_> http://archive.ubuntu.com/ubuntu/pool/main/u/ubuntu-docs/
[03:01] <kiko> when did it appear in the archive, mdke_?
[03:02] <mdke_> kiko, i don't know, it was built about 24 hours ago, so maybe soon after that?
[03:02] <kiko> does the file time not suggest that
[03:03] <mdke_> about 11 hours ago? maybe
[03:03] <mdke_> i don't know
[03:04] <mdke_> it finished building about 26 hours ago according to https://launchpad.net/+builds/+build/170866
[03:05] <kiko> mdke_, okay, we'll need cprov to look into it and figure out why apt-ftparchive isn't doing it's thing
[03:05] <mdke_> shall I file a bug, or will you guys look into it without?
[03:05] <kiko> mdke_, file a bug and ping cprov
[03:06] <mdke_> thanks kiko
[03:06] <kiko> enjoy
[03:09] <mdke_> cprov, bug #32721 for you. Thanks!
[03:09] <Ubugtu> malone bug 32721 in soyuz "Package built for breezy-updates is not appearing in the package index" [Major,Unconfirmed]  http://launchpad.net/bugs/32721
[03:19] <tseng> is it a known issue that closing any bug makes launchpad  oops?
[03:20] <kiko> tseng, no, it is not. OOPS code please.
[03:20] <tseng> kiko: OOPS-55C321
[03:20] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/55C321
[03:20] <tseng> kiko: this is the second bug i've tried to close with the same result
[03:21] <kiko> hold tight london
[03:21] <kiko> BjornT, ping
[03:21] <BjornT> pong
[03:21] <kiko> I need a band-aid for tseng 
[03:21] <kiko> BjornT,     from_addr = format_address(person.displayname, person.preferredemail.email)
[03:21] <kiko> AttributeError: 'NoneType' object has no attribute 'email'
[03:22] <kiko> BjornT, we need a band-aid and a needle to test it
[03:27] <BjornT> hmm, i can't say that i understand why this is happening. person should be the currently logged in user, and the error indicates that it doesn't have a preferred email address. i'll take a closer look...
[03:27] <tseng> BjornT: there is a back story
[03:27] <tseng> which may or may not be relevant
[03:27] <tseng> i tried to merge two accounts, one with a non-working email address
[03:27] <tseng> so one account got stuck in limbo
[03:28] <tseng> stevea merged it for me by hand after gpg verification
[03:28] <tseng> the account might be a bit non-standard due to this
[03:29] <kiko> tseng, what's the account name?
[03:29] <tseng> 'brandon'
[03:29] <kiko> you have a preferred email address
[03:30] <kiko> it is listed on your page
[03:30] <kiko> what was the old address?
[03:30] <tseng> brandon@brandonhale.us was the broken one
[03:30] <kiko> do you remember the launchpad name for it?
[03:30] <tseng> brandon-ubuntu was the other account
[03:30] <ddaa> okay, the commit-pass-to-subprocess thing does not work here :(
[03:31] <kiko> tseng, are you logged in now?
[03:31] <tseng> kiko: as brandon
[03:31] <kiko> are you sure it's as brandon? can you click on the link next to Log Out to confirm?
[03:32] <tseng> https://launchpad.net/people/brandon
[03:32] <bradb> kiko: I noticed that the Dapper bugs are all cleaned up now. Yay to dholbach.
[03:32] <kiko> tseng, okay, then I'll leave you in BjornT's hands because it is not an obvious case of bustage
[03:32] <tseng> kiko: ok.
[03:32] <Kamion> bradb: was there a reason why they *all* had to be closed? I was using the dapper tasks to remember certain things I wanted to fix for dapper, and I've just lost that information.
[03:32] <Kamion> bradb: because "target fix to release" creates a dapper task
[03:32] <BjornT> kiko: have you executed the last sql query in the oops report, to see what it returns?
[03:33] <kiko> Kamion, it won't create them any longer after tuesday
[03:33] <kiko> Kamion, you should use milestones instead
[03:33] <kiko> releases are for backports
[03:33] <bradb> Kamion: yeah, that's a UI bug that I've landed a fix for. things you want to fix for dapper should use milestones (again, our fault on the UI)
[03:33] <kiko> milestones are for the future
[03:33] <Kamion> where is the UI for that?
[03:33] <bradb> Kamion: +editstatus
[03:33] <BjornT> kiko: also, please check 'select name from person where id=301599
[03:33] <Kamion> ah
[03:33] <dilys> Merge to devel/launchpad/: [trivial]  Add an assert in PersonSet.getByEmail() to help debugging https://launchpad.net/products/launchpad/+bug/31755 (r3194: Guilherme Salgado)
[03:34] <Kamion> that has both "dapper" and "ubuntu-6.04"
[03:34] <kiko> rock on dilys 
[03:34] <Kamion> make your minds up :P
[03:34] <bradb> Kamion: Those are your guys' milestones, not ours
[03:34] <kiko> Kamion, blame mdz! :)
[03:34] <Kamion> I frequently do
[03:34] <Kamion> mdz is Canada
[03:34] <kiko> BjornT, brandon-ubuntu-merged
[03:34] <bradb> The "dapper" one was there before the important, the "ubuntu-*" ones came from Bugzilla, IIRC
[03:34] <bradb> s/important/import/
[03:35] <Kamion> bradb: please add a way to search by milestone
[03:35] <BjornT> tseng: can you try to logout, and then login again, to see if it helps?
[03:36] <tseng> BjornT: mm, ok
[03:37] <tseng> BjornT: whatdyaknow
[03:37] <tseng> BjornT: works.
[03:37] <bradb> Kamion: er, yeah, that's a bug. I've got a big landing in code review right now which changes all the bug listings and advanced search screen, so I can easily sneak in the milestone search.
[03:37] <tseng> BjornT: thanks a lot
[03:37] <Kamion> bradb: yes please, I need to not lose track of bugs where my manager has said "please don't forget about this for dapper"
[03:37] <bradb> jamesh: Any review news, btw? :)
[03:37] <BjornT> tseng: ok, that's good to hear. it was probably due to the manual merge
[03:42] <carlos> cprov: hi
[03:42] <cprov> carlos: hi
[03:42] <carlos> cprov: I'm back with DSL, just in time ;-)
[03:42] <cprov> carlos: good, have talked with pitti about our situation
[03:42] <carlos> cprov: Thinking it twice, you don't need any patch from me. The changes I did are not executed by soyuz but from manually uploaded files
[03:43] <cprov> carlos: uhm ...
[03:43] <carlos> cprov: rollout your changes and I will try to get mine reviewed, landed and cherrypicked as soon as possible (that's today)
[03:43] <carlos> kiko: hi, around?
[03:44] <Kamion> bradb: should I file a bug as a memory aid?
[03:44] <cprov> carlos: I've already rolled out my relevant parts,i.e., your code is there ;)
[03:44] <carlos> hmm, in fact, my changes are not really needed for soyuz, but for manual uploads so it's not even so urgent
[03:44] <carlos> cprov: well, I mean, any other change that was not already on your branch
[03:45] <cprov> carlos: AFAICS, you won't be able to cherrypick anything til monday, no stub
[03:45] <carlos> cprov: when will martin upload the new pkgstriptranslations?
[03:45] <cprov> carlos: the other changes I have are planned for tuesday
[03:45] <bradb> Kamion: sure, that would help. can you please assign it to me, and mark it High priority and In Progress?
[03:45] <cprov> carlos: so, I've fixed a deadline to tuesday
[03:45] <carlos> cprov: that's ok, as I said, it's not affected directly by your uploads from soyuz, that should work anyway
[03:45] <cprov> carlos: or as soon as you can release your fix
[03:45] <carlos> cprov: so no translations for dapper until tuesday??
[03:46] <carlos> cprov: ok, let me tell it again. You don't need any patch from me or on production for dapper imports. At least not that I'm aware of
[03:46] <kiko> carlos, always around.
[03:46] <carlos> cprov: if your part is already done, let's do it now
[03:46] <cprov> carlos: pitti doesn't like the idea of extra clicks exposed by the lack of your fix
[03:47] <carlos> cprov: I did a mistake when I talked with you
[03:47] <cprov> carlos: what was it ?
[03:47] <carlos> cprov: those clicks should not affect soyuz imports
[03:47] <carlos> because the translations are not uploaded against a potemplate but a source package
[03:47] <carlos> so we need the initial review anyway
[03:48] <cprov> carlos: so why those tests in mawson was wrong ? 
[03:48] <cprov> were
[03:48] <carlos> cprov: so the changes I'm doing atm are useful only for manual imports not for the automatic path
[03:48] <ddaa> maybe it's just connecting to the wrong db...
[03:48] <cprov> carlos: I lost the track then, why did you said the mawson's results were wrong ?
[03:49] <carlos> cprov: Because the IPOFile.path was wrong on the previous import
[03:49] <carlos> cprov: it was for another problem that should not appear now
[03:49] <carlos> cprov: I tested it manually here and it worked
[03:49] <cprov> carlos: then it won't work now too, we have no fix 
[03:49] <carlos> but you just remind me to check it with raw DB access
[03:49] <cprov> carlos: why did it failed in mawson ?
[03:50] <carlos> cprov: that's a problem only with old imports into dapper
[03:50] <carlos> cprov: we imported them on december
[03:50] <carlos> with wrong settings
[03:50] <Kamion> bradb: done, bug 32728; thanks
[03:50] <Ubugtu> malone bug 32728 in malone "need search by milestone facility" [Normal,In progress]  http://launchpad.net/bugs/32728
[03:50] <cprov> carlos: the same thing will happen again in production.
[03:50] <bradb> Kamion: cheers
[03:50] <kiko> spiv, ping?
[03:50] <carlos> we will need to fix them by hand and next time it will work
[03:51] <kiko> Kamion, bradb: uhm, you can search by milestone today.
[03:51] <carlos> cprov: but the amount of broken packages is low as we stopped the old import procedure long time ago already
[03:51] <kiko> bradb, make sure your branch does not regress that, btw
[03:51] <carlos> cprov: dude, but only for the 10-15 packages that were imported by mistake on dapper
[03:51] <Kamion> kiko: how?
[03:51] <cprov> carlos: so, do it first in mawson, I really want to see them fixed
[03:51] <bradb> kiko: only on upstreams, as best i can tell
[03:51] <kiko> Kamion, well, +bugs-advanced
[03:51] <carlos> cprov: ok, then I will need to run the poimport script on mawson
[03:52] <kiko> Kamion, however, it is currently broken in production -- fix is in PQM and it will work on tuesday
[03:52] <Kamion> kiko: which does not exist on my person page ...
[03:52] <carlos> cprov: do I have permissions to sudo to the launchpad user as I used to have?
[03:52] <Kamion> and the advanced search option from there doesn't have a milestone option
[03:52] <kiko> damn
[03:52] <kiko> bradb is right
[03:52] <kiko> that is CRACK
[03:52] <cprov> carlos: nothing changed there, if you had, you still having, try ASAP
[03:52] <carlos> kiko: sorry for ignore your pong... O:-)
[03:52] <kiko> blah
[03:53] <bradb> kiko: If I land the fix in the next hour or so, do you think it can make it into the next prod rollout?
[03:53] <kiko> bradb, yes.
[03:53] <carlos> kiko: I thought I would need an urgent review from you today, but it will not needed as urgent so just ignore the ping ;-)
[03:53] <kiko> thank god
[03:53] <carlos> cprov: ok
[03:53] <bradb> kiko: ok, working on it now
[03:53] <cprov> carlos: I'm leaving for lunch now, you can do whatever you  want (can) in mawson's DB, when I come back we can redo the uploads and see if it works
[03:54] <carlos> cprov: ok
[03:54] <carlos> cprov: just a question... will emails be sent out from mawson?
[03:54] <kiko> bradb, notify stub of the patch via email
[03:54] <bradb> kiko: will do
[03:54] <cprov> carlos: never
[03:55] <carlos> ok
[03:55] <cprov> carlos: from initZopeless
[03:55] <carlos> cprov: yes, initZopeless
[03:55] <cprov> carlos: find pitti and tell him we may be able to switch pkgstriptranslation soon (today or tomorrow)
[03:56] <cprov> carlos: will be back in 1 hours, play fair in mawson';)
[03:56] <carlos> cprov-lunch: ok, thanks!
[04:03] <seb128> hi
[04:03] <kiko> hello seb128 
[04:03] <kiko> what's up?
[04:03] <seb128> how often is update the "assignee" to the bug list?
[04:03] <kiko> sorry?
[04:04] <seb128> I've the feeling that I lot of bug I triage stay unassigned on https://launchpad.net/distros/ubuntu/+bugs?field.searchtext=&orderby=-datecreated&search=Search
[04:04] <seb128> open that page
[04:04] <seb128> look for #32718
[04:04] <seb128> it's "need info (unassigned)"
[04:04] <seb128> but the task is assigned to desktop-bugs in fact
[04:05] <kiko> seb128, you are in the wrong context, but.. weird
[04:05] <seb128> "wrong context"?
[04:05] <kiko> seb128, I think it's a bug
[04:05] <seb128> it happens a lot, I thought it was some of "bug list is update hourly or so", ie: lag
[04:05] <seb128> should I open a bug so?
[04:05] <kiko> could it be?
[04:06] <kiko> bradb, can you check out seb128's question?
[04:06] <seb128> I don't know, I'm not an lp dude
[04:06] <kiko> seb128, I'd mail the mailing list instead
[04:06] <seb128> which one? :)
[04:06] <seb128> launchpad-users list ?
[04:06] <bradb> kiko, seb128: yeah, it's a bug
[04:06] <kiko> or launchpad, it's the same
[04:06] <kiko> aha
[04:07] <bradb> for certain statuses, the code is erroneously appending a hardcoded " (unassigned)" to the display value
[04:09] <kiko> bradb, argh. is that reported?
[04:09] <kiko> gross
[04:09] <seb128> it makes bug triage quite annoying
[04:09] <kiko> BjornT, are you saying the merge isn't clearing out session information?
[04:09] <seb128> (ie: if it's very low on your priority list you may want to bump it)
[04:09] <bradb> kiko, seb128: bug 29671
[04:10] <Ubugtu> malone bug 29671 in malone "Listing shows bug "unassigned" even when it's assigned" [Normal,Confirmed]  http://launchpad.net/bugs/29671
[04:10] <bradb> I can fix that one today too, easily enough.
[04:10] <kiko> cool
[04:10] <kiko> thanks
[04:10] <kiko> bradb, https://launchpad.net/distros/ubuntu/dapper/+source/nut/+bug/6585/+viewstatus
[04:10] <seb128> bradb: thanks dude :)
[04:10] <Ubugtu> malone bug 6585 in nut "Hotplug dependency in nut-usb package" [Major,Confirmed]  
[04:10] <bradb> no prob
[04:10] <kiko> bradb, can you confirm that crashes, and see what you can do about it?
[04:11] <carlos> cprov-lunch: 100% confirmed that the problem is what I told you.
[04:11] <carlos> cprov-lunch: to do the test you want to do, I need that a package is uploaded twice (that's with different versions)
[04:11] <bradb> kiko: That's an easy enough one to fix today too, if you want.
[04:12] <carlos> cprov-lunch: when you are back we will talk about it
[04:12] <kiko> bradb, I do -- see if it's reported, btw
[04:12] <kiko> bradb, BjornT: I'd like us to move forward on making the view/editstatus split go away, and have just +status
[04:12] <kiko> what do you guys think of that?
[04:13] <bradb> kiko: Presumably it would be read-only if you can't edit it, right?
[04:13] <kiko> correct.
[04:13] <bradb> I think that would be good.
[04:14] <BjornT> kiko: yeah, that seems to be the problem, that the session wasn't cleared out. could you file a bug about it? i don't know the procedure of how admins can merge accounts.
[04:14] <bradb> kiko: I can't find a bug on the +viewstatus problem. I'll report and take it.
[04:15] <BjornT> kiko: yeah, merging the two pages seems like a sane thing to do.
[04:15] <kiko> salgado, can you coordinate a bug report with BjornT on this matter? I need to skip out
[04:15] <kiko> cool.
[04:15] <jblack> kiko: ping
[04:15] <salgado> eh?
[04:15] <BjornT> bradb: maybe bug 32709?
[04:15] <kiko> salgado, merging apparently isn't clearing out session data for authed users.
[04:15] <Ubugtu> malone bug 32709 in launchpad "Cannot view status of bug in some cases" [Normal,Unconfirmed]  http://launchpad.net/bugs/32709
[04:16] <bradb> BjornT: oh, good call
[04:16] <bradb> thanks
[04:16] <salgado> I'll have a look in one second.
[04:16] <kiko> thanks salgado 
[04:17] <salgado> kiko, "Care must be taken to ensure that a branch actively being updated via rsync is not accessed by anything."
[04:17] <salgado> from https://wiki.launchpad.canonical.com/RocketFuelSetup
[04:17] <kiko> :)
[04:17] <jblack> kiko: a branch being written via rsync (which lp devs use) is inconsistant during write. Its on the RocketFuelSetup, but probably hasn't been publicised well enough
[04:17] <kiko> yeah, I know now :)
[04:19] <jblack> I was going to be cute with a sentence with about 20 knows in it. 
[04:19] <jblack> Know that I now know that you didn't know what you now know... 
[04:20] <jblack> Is the lack of knowlege about this still a general issue?
[04:21] <jblack> salgado: nope. its not your fault. That document postdates your move to bazaar-ng
[04:25] <salgado> well, at least know we know it and matsubara won't have problems anymore
[04:26] <salgado> and I don't think this is a general issue. it applies to us because we have a prebuilt branch that we sync from rocketfuel and that's shared between me, kiko and matsubara 
[04:26] <kiko> yeah.
[04:26] <kiko> we suck.
[04:27] <jblack> Ok. Fine. To the back of the station wagon with you.
[04:27] <jblack> I think its my fault
[04:29] <kiko> I ride mexican-style with pride
[04:45] <sladen> is there a feature to automatically refile a malone-originated bug in a remote bugtracker;  is in the support only passive, rather than active
[04:45] <sladen> or a generated link to  bugzilla.upstream.com/...filebug?package=$this_one
[04:46] <sladen> at the moment I'm doing that by hand and then adding the links.  Having Malone do it would mean that it was linked automatically
[04:47] <bradb_> sladen: Malone doesn't support filing the bug upstream, ATM.
[04:47] <bradb> It's not impossible that it might in the future.
[04:47] <sladen> bradb: nod. okie, thanks
[04:48] <seb128> bradb: it should not do a raw forward imho
[04:48] <seb128> bradb: but a pointer to "newbug" page from upstream could be nice :)
[04:48] <bradb> I can see issues with reporting dups upstream.
[04:48] <bradb> Or, at least, that being more likely to happen when done blindly through Malone.
[04:48] <seb128> and that's also quality of what we forward
[04:48] <seb128> often we get informations and cleanup the bug before forwarding
[04:49] <bradb> seb128: Yeah, the link to the upstream filing page would seem a good idea, at the least.
[04:49] <seb128> bradb: BTW how is placed the "fix formating of comments" on your list?
[04:50] <seb128> that makes backtraces $)$:! to read
[04:50] <bradb> seb128: Not on the list. That seems like an mpt thing, but kiko would know where that stands. I feel your pain.
[04:50] <sladen> . o O {if a little more of the source was opened, more people would be willing to fix the small irriating bugs like line-wrapping...}
[04:50] <bradb> (It's particularly brutal in a three-column layout.)
[04:50] <seb128> like have #7 .... #8
[04:50] <seb128> function #9
[04:51] <seb128> kiko: do you know about that? :)
[04:51] <kiko> let me see
[04:52] <kiko> seb128, indeed, mpt has not given us a good answer on that. is it frustrating you?
[04:52] <seb128> yep
[04:52] <kiko> I can escalate this and ensure we find a solution if you yell loud enough on the list
[04:52] <kiko> tip: yelling VERY loud works
[04:52] <bradb> sladen: It'd be hard to usefully open source small pieces of LP for this kind of thing. e.g. To usefully Open Source Malone, you'd almost have to open up all of LP for anyone to have a hope of launching the app locally.
[04:52] <seb128> kiko: have a look on current comment from https://launchpad.net/malone/bugs/32034
[04:52] <Ubugtu> malone bug 32034 in gdm "GDMsetup immediately crashes in Dapper." [Major,Unconfirmed]  
[04:52] <seb128> kiko: the valgrind log
[04:53] <seb128> "==21124== by 0x8053DA0: setup_user_combobox_list (gdmsetup.c:1619) ==21124== by 0x8053F3D: setup_user_combobox (gdmsetup.c:1649) ==21124== by 0x805C9F8: setup_security_tab (gdmsetup.c:5002) ==21124== by 0x8060380: setup_gui (gdmsetup.c:6270)"
[04:53] <seb128> stuff like that
[04:53] <kiko> seb128, yeah. horrible. please cry out loud -- people don't believe me when I say our comment formatting is a disaster
[04:53] <seb128> are ...
[04:53] <seb128> grrrrrr
[04:53] <kiko> seb128, there would be a trivial workaround, not perfect, but perhaps:
[04:53] <kiko> offering a raw text view of a comment
[04:53] <kiko> what do you think?
[04:53] <seb128> why  prevent you to fixing the comment rendering?
[04:53] <seb128> bugzilla does it right, it never screw backtraces .. should be possible :)
[04:53] <kiko> seb128, there's a couple of issues, IIRC
[04:54] <kiko> fixed-width fonts
[04:54] <seb128> a new line is a '\n' no?
[04:54] <seb128> I mean current layout eats '\n' chars or something like that
[04:54] <kiko> the current layout is html
[04:54] <kiko> with some fancy formatting applied
[04:54] <kiko> it works well except when it doesn't
[04:54] <sladen> kiko: the HUGE FONT, narrow overfilled screen, urls that get wrapped and broken at '-' dashes and tables that don't fit make MALONE LOOK TEH CRAP.
[04:55] <seb128> kiko: anyway a "raw comment" would be better yep
[04:55] <seb128> it would give an easy way to get a decent formatting if you didn't get the mail
[04:55] <kiko> sladen, the narrow screen is going to be fixed soon. the RHS portlet is dead, we just need to bury it.
[04:55] <bradb> The huge font has me using <small> in any page that I want to look non-crap (e.g., the new bug listings, when jamesh gets around to reviewing them.)
[04:55] <kiko> and mpt needs to wake up and do it
 sucks.
[04:55] <bradb> Yeah, I should probably use CSS
[04:56] <kiko> unless it's used to mark up small portions of text
[04:56] <kiko> sladen, the url wrapping is only in email, IIRC
[04:56] <sladen> bradb: how come the font is being touched in the first place, it should be left at the browser default
[04:56] <kiko> the tables that don't fit are just fuckage caused by the RHS portlets
[04:56] <bradb> sladen: Dunno.
[04:57] <kiko> sladen, an mpt question
[04:57] <bradb> kiko: In this case, it's not really about content not fitting, so much as that our default font isn't very aesthetically pleasing, IMHO, (and apparently, IsladenHO)
[04:58] <kiko> there's a way to fix that
[04:58] <kiko> trivial it! :)
[04:58] <bradb> Can we do that? LP-wide font-size desuckage?
[04:59] <kiko> we could, yeah
[04:59] <kiko> let's talk about it with mpt
[04:59] <bradb> sounds like a plan
[04:59] <sladen> kiko: yes, wrapping only in email (the rest of the time it just goes off the RHS of my screen :)
[04:59] <kiko> I'm outta here today
[05:05] <sladen> bradb: I remember from trying to use 'smaller' and friends ages ago that they /don't work as expected/ and it's better to use 1.2^n scaling:  map(lambda x: 100*(1.2**x), map(float, range(-3,3)))  eg.  58%, 69%, 83%, 100%, 121%, 144% ... which match the "natural" scaling of fonts
[05:06] <sladen> which I found to work across all browsers/combos
[05:08] <bradb> right. i imagine mpt is aware of this too, so he should be able to help us sort it out
[05:09] <sladen> bradb: bug fileage time?
[05:09] <sladen> (what I don't understand is that all the scaling are < 100% and yet the font is clearly bigger...)
[05:10] <bradb> sladen: Sure, a bug should probably be filed. Do you want to file it, or should I?
[05:15] <sladen> bradb: I'm playing with the CSS at the moment, I'll post a suggested patch for people when I'm happy
[05:15] <sladen> in the meantime, turning off the CSS altogether is quite refreshing :)
[05:16] <bradb> heh
[05:18] <salgado> BjornT, can you give me more context on the "merging apparently isn't clearing out session data for authed users." problem? I can't seem to find anything in my backlog
[05:20] <BjornT> salgado: sure. the oops in question was OOPS-55C321
[05:20] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/55C321
[05:21] <BjornT> what seems to have happen is that steve merged tseng's two accounts brandon and brandon-ubuntu, leaving only brandon
[05:21] <BjornT> but it seems at the time that he was logged in as brandon-ubuntu, and since the session information didn't get cleared, he stayed logged in, and did stuff without having a preferred email address
[05:22] <BjornT> at least that's the theory. is it clear?
[05:23] <salgado> as clear as it gets. :)
[05:23] <salgado> thanks BjornT, I'll check some things and will file a bug on that
[05:23] <BjornT> cool, thanks
[05:28] <BjornT> salgado: how confident are you of the test coverage for person vocabularies? :) if i change __contains__ not to issue any db queries, should i add some more tests?
[05:30] <cprov> carlos: duderino, what's up ?
[05:30] <carlos> cprov: hi
[05:31] <carlos> cprov: I found an easier way to show you that it's working
[05:31] <cprov> carlos: show me ;)
[05:31] <carlos> cprov: https://dogfood.ubuntu.com/rosetta/imports
[05:32] <cprov> carlos: ehe, kinda slow at mawson (huge)
[05:32] <cprov> carlos: yup
[05:32] <carlos> cprov: is it a problem with the page? or the server?
[05:32] <cprov> carlos: I've loaded it normally
[05:33] <carlos> cprov: The Finnish entry was moved automatically to the first list of resources ready to be imported when I fixed manually the path
[05:33] <cprov> carlos: mawson isn't fast, page isn't small
[05:33] <carlos> so the system was able to decide where should it go
[05:33] <cprov> carlos: didn't get it very well
[05:33] <carlos> cprov: so the problem was, as I supposed, the POFile.path field
[05:34] <cprov> carlos: what did you fixed 
[05:34] <carlos> that is empty always
[05:34] <carlos> cprov: I did an update of that row
[05:35] <carlos> fixing the path
[05:35] <cprov> carlos: what should it be ? rather than empty ?
[05:35] <carlos> the same as the file being imported
[05:36] <cprov> carlos: so, do we need to do those fixes in production in order to get it working properly ?
[05:36] <carlos> when we fix it "manually" using the web interface, next time it's already correct so the import will be done automatically
[05:37] <carlos> cprov: no, the website allows us to do that
[05:37] <cprov> carlos: uhm .. that's good
[05:37] <carlos> cprov: so I would say, go, go, go!
[05:37] <carlos> but pitti is not online
[05:37] <cprov> carlos: eheh, call him
[05:37] <carlos> cprov: I was waiting for you
[05:38] <carlos> to know if you know why is not online ;-)
[05:38] <carlos> before calling
[05:38] <cprov> carlos: he just left before me, don't know why 
[05:38] <carlos> cprov: anyway, is all ready on your side to do the pkgstriptranslations update?
[05:38] <carlos> ok
[05:39] <cprov> carlos: what time is there, in Germany ? +1 by you ?
[05:39] <carlos> cprov: I want to be sure so I call Martin to request him the upload ASAP
[05:39] <carlos> same as here
[05:39] <carlos> 17:39
[05:39] <sladen> bradb: btw, do file it and post me the #, that way it'll get your thoughts too
[05:39] <cprov> carlos: yes, call him and say the words: DO IT ;)
[05:39] <carlos> :-D
[05:39] <carlos> cool, thanks
[05:40] <cprov> carlos: I hope i can assist the first run of it today yet
[05:40] <carlos> calling....
[05:40] <cprov> carlos: thank you, got the job organized and done just in time .
[05:40] <carlos> no answer
[05:45] <carlos> cprov: seems like he left already for the weekend
[05:46] <cprov> carlos: ohh this is bad, can we upload his last pkg from p.u.c ?
[05:47] <mdke> cprov, did you see my breezy-updates bug? is there any more info I can give you on it?
[05:47] <carlos> cprov: asking atm
[05:48] <salgado> BjornT, I've refactored these vocabs a few times already (and the last time it was almost a complete rewrite), and I haven't seen bugs reported on them, so I guess the test coverage is good
[05:48] <cprov> mdke: sorry, not yet, one sec and I can handle it for you
[05:50] <BjornT> salgado: ok, good. i'll let you review the changes later.
[05:50] <mdz> bradb,Kamion: I didn't create any milestones
[05:51] <bradb> sladen: bug 32749
[05:51] <Ubugtu> malone bug 32749 in launchpad "Launchpad fonts are too big" [Normal,Confirmed]  http://launchpad.net/bugs/32749
[05:51] <salgado> BjornT, sure
[05:52] <bradb> mdz: right, I don't know who added the "dapper" milestone, but oh well
[05:53] <sladen> bradb: groovy
[05:55] <mdz> bradb: the sab?
[05:55] <bradb> could be
[05:56] <carlos> cprov: it's done
[05:57] <carlos> cprov: Martin will do the upload as soon as he arrives home
[05:57] <carlos> cprov: in 3 hours or so
[05:57] <carlos> cprov: will you be online at that time?
[05:57] <cprov> carlos: very good carlos 
[05:57] <cprov> carlos: yes, but it will take another 3 hours to be compiled and published 
[05:58] <carlos> oh
[05:58] <cprov> carlos: I will take care of it properly for us 
[05:58] <cprov> carlos: don't worry
[05:58] <seb128> bradb: "dapper" was created before the bugzilla import
[05:58] <carlos> cprov: well, I should be online at that time (unless my DSL line fails again)
[05:58] <seb128> and bugzilla import created the "ubuntu-..."
[05:58] <cprov> carlos: let's see
[05:58] <carlos> cprov: thanks for all
[05:59] <carlos> kiko_smtb: did you see it?
[05:59] <carlos> smtb.... what's that?
[05:59] <carlos> cprov: I'm going to update the status answering your email
[06:00] <cprov> carlos: please, CC LP don't forget
[06:00] <carlos> cprov: sure
[06:01] <cprov> carlos: something related to "montain bike", ohhh, crap !
[06:01] <carlos> :-P
[06:13] <carlos> cprov: done
[06:28] <cprov> carlos: good
[06:35] <seb128> bradb: around?
[06:37] <seb128> bradb, jamesh: could we get https://bugzilla.ubuntu.com/show_bug.cgi?id=13169 imported?
[06:37] <Ubugtu> ubuntu bug 13169 in nautilus "evil breezy unmounting action due to async filesystem" [Normal,Upstream]  
[06:40] <seb128> bradb: 
[06:40] <seb128>   32620. poor string in the window switcher button
[06:40] <seb128> in update-manager (Ubuntu), unconfirmed 
[06:41] <seb128> why doesn't it say it's assigned to mvo?
[06:41] <seb128> same issue as for the unconfirmed pointed before?
[06:53] <bradb> seb128: It seems as though there were already two bugs opened that were watching that bug: https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/13169
[06:53] <bradb> Which, I guess, is why it wasn't imported.
[06:54] <bradb> seb128: So, you want it imported anyway?
[06:54] <seb128> yep
[06:54] <seb128> those 2 bugs are useless, the bugzilla one has a lot of comments compared to them
[06:55] <seb128> one of the 2 is an another issue
[06:55] <bradb> ok, i'll mail james
[06:55] <seb128> it says to a comment:
[06:55] <seb128> "
[06:55] <seb128> Bug #5049 (the eject failure) was fixed recently in Dapper.
[06:55] <seb128> As for the progress bar, this is https://bugzilla.ubuntu.com/show_bug.cgi?id=13169."
[06:55] <Ubugtu> malone bug 5049 in kaffe "kaffe: merge new debian version" [Normal,Fix released]  http://launchpad.net/bugs/5049
[06:55] <Ubugtu> ubuntu bug 13169 in nautilus "evil breezy unmounting action due to async filesystem" [Normal,Upstream]  
[06:55] <seb128> I don't really why you did import them in that case, that's the first time
[06:56] <seb128> since we worked with bugzilla before the import, the bugzilla is almost always the useful one
[06:56] <bradb> re: the bug not showing mvo being assigned, it's caused by the same bug you mentioned earlier. that code is just b0rked.
[06:56] <seb128> and the launchpad one is a one comment "known as bugzilla nnn"
[06:56] <seb128> bradb: ok, thank you :)
[07:01] <BjornT> salgado: ping
[07:01] <bradb> seb128: Just to confirm, you'd ideally like us to have imported ALL Bugzilla bugs, right? Including the ones that already had manually added watches in Malone at the time the import was run?
[07:02] <salgado> BjornT, pong
[07:02] <seb128> bradb: yep
[07:03] <BjornT> salgado: could you please review https://chinstrap.ubuntu.com/~dsilvers/paste/filezhRe0X.html, it's quite small. it fixes bug 2045 and makes sure that 'obj in person_vocabulary' doesn't issue a db search.
[07:04] <salgado> come on Ubugtu, what's bug 2045?
[07:04] <salgado> ah, right. it's private
[07:06] <salgado> BjornT, Hmmm, I guess this is a good oportunity for me to read all 7 bugmail from that bug I have in my inbox. :)
[07:06] <bradb> seb128: You've got a copy of the email I sent. Thanks for letting me know of the problem.
[07:06] <BjornT> salgado: could be :)
[07:06] <seb128> bradb: did get the mail yet, but thank you :)
[07:26] <salgado> BjornT, ValidPersonOrTeamVocabulary.__contains__() uses the "foo_object in Foo.select(query)" syntax, which will issue a single "select * from foo where <query> and id = foo_object.id". I guess you knew that already, but you think it's worth adding around 30 lines of code to avoid a query that should run almost instantaneously?
[07:28] <salgado> (or maybe you have another reason that I can't see for the changes in the __contains__ method)
[07:37] <BjornT> salgado: well, my main motivation was to minimize the number sql queries issued. but as you say, the avoided queries are probably quite quick. if you want, i can revert that part.
[07:39] <salgado> BjornT, I'd like to check with stub first if avoiding these queries are really worth something, because with the changes you've done, we now have two different places in each vocab where we need to code the extra logic for that vocab, and it used to be only one
[07:40] <salgado> what do you think of holding the __contains__() changes until we talk with stub?
[07:41] <BjornT> salgado: sure, sounds sane.
[07:48] <salgado> BjornT, so, you just removed the _getFormInput(), which was the one calling vocabulary.search()?
[07:49] <BjornT> salgado: yes. then i modified popup.pt, so that the select box with search results get shown only if there's not an exact match.
[07:50] <salgado> right, and why do we need to make IHugeVocabulary extends IVocabularyTokenized?
[07:55] <BjornT> salgado: it's because SinglePopupWidget expects the vocabulary to provide IVocabularyTokenized. that dependency wasn't added with this patch, just added it since it should be like that.
[07:55] <salgado> ah, right
[07:56] <salgado> well, I don't have anything to complain about that patch. you can merge wirh r=salgado
[07:57] <BjornT> thanks
[08:35] <dilys> Merge to devel/launchpad/: [r=salgado]  fix bug 2045, prevent IHugeVocabulary widget from performing searches if it gets an exact match. only display search results if there's no exact match. should prevent timouts from happening when assigning someone to a bug, spec, etc. (r3195: Bjorn Tillenius)
[08:37] <bradb> Hm, that merge seems like a bug, to me.
[08:38] <bradb> An exact match != the desired match necessarily.
[08:40] <bradb> I vaguely remember there being a bug open on that behaviour, but maybe I'm remembering incorrectly.
[08:42] <salgado> bradb, https://launchpad.net/products/launchpad/+bug/2045
[08:42] <salgado> I pointed out what you said too, but this is a temporary solution
[08:42] <salgado> and I don't think it'll cause us trouble right now
[08:45] <bradb> Users will decide, I guess. :)
[08:47] <bradb> an example of how one could go easily wrong would be to search for, literally, "foo"
[08:47] <bradb> there's an actual "foo", but there are also dozens of variants
[08:48] <salgado> the same with 'carlos'
[08:48] <bradb> indeed
[08:48] <carlos> no dudes, I'm unique!
[08:48] <carlos> :-P
[08:49] <bradb> heck, even bradb
[09:17] <BjornT> is it just me, or has the test suite become quite a bit slower?
[09:18] <BjornT> it takes twice as long for me to run all the functional tests, compared with a few weeks ago
[09:19] <BjornT> bradb: re bug 2045, if the users want to search for a value, why not use the search form? ;)
[09:21] <bradb> BjornT: That makes logical sense, but the conversation between user and system is more a mutual co-operation trying to achieve some goal, rather than a set of discrete correct or incorrect actions. Users actions are often approximations of what they really mean.
[09:22] <bradb> But, maybe I misunderstand the fix then: if it only specifically chooses "foo" on exact match when that was typed directly into, say, +editstatus, then it's probably ok.
[09:24] <bradb> From "only display search results if there's no exact match", I thought that was referring to the search form.
[09:24] <BjornT> bradb: exactly, the merge message is a bit ambiguous. and by looking at the oops related to that widget, that is what most users expect
[09:24] <CarlFK> what are the chances of getting the "add attachment" option to take a URL so that I can post files that arn't on my file system, like http://dev.personnelware.com/carl/temp/Feb24/ubuntu-installs/a/fdisk.txt
[09:25] <BjornT> bradb: yeah, that sentence referred to the search results that are displayed if you don't use the "Choose" popup search
[09:25] <CarlFK> and also, allow posting multiple files as a group so that I can stop using the file name as both the title and comment 
[09:26] <bradb> BjornT: ok, n/m then :P
[09:27] <CarlFK> is there a proper place to post sugestions like these ?
[09:30] <BjornT> CarlFK: the easiest way is probably to file bugs at https://launchpad.net/products/malone/+filebug
[09:31] <CarlFK> k - thanks
[09:32] <CarlFK> I like this - don't have to pick a package name ;)
[09:32] <CarlFK> worst part about reporting ubuntu bugs 
[09:33] <mpt> You don't have to pick a package name when reporting Ubuntu bugs either
[09:33] <CarlFK> hey look at that... 
[09:33] <mpt> bug 31638
[09:34] <Ubugtu> malone bug 31638 in malone ""Package Name" field when reporting bug should be more obviously optional" [Normal,Confirmed]  http://launchpad.net/bugs/31638
[09:34] <CarlFK> good deal
[09:51] <Keybuk> bradb: does Malone *have* to have an "Are you sure?" for Unsubscribe
[09:51] <Keybuk> it's damned annoying
[09:51] <Keybuk> couldn't it just do it, on the basis that subscribing again is easy
[09:53] <bradb> Keybuk: from the man who brought you three column layouts...
[09:53] <bradb> no, we needn't ask that annoying question
[09:54] <seb128> do we need it for subscribing too? :)
[09:55] <seb128> if I click to subscribe on a bug, that's because I want too
[09:56] <bradb> I wasn't even aware of that, because I never have to sub/unsub, but those annoyances should be removed, yeah.
[10:00] <bradb> BjornT: I wonder if you might have time to review a patch for an urgent bugfix? (5 files changed, 45 insertions(+), 36 deletions(-))
[10:00] <bradb> It's just adding the milestone search widget to the person and distro search forms.
[10:02] <BjornT> bradb: i might have time, put it up somewhere and i'll have a look at it
[10:02] <bradb> BjornT: ok, thanks, just quickly cleaning up the diff
[10:04] <BjornT> hmm, i wonder if someone would object if i suggested reverting the patch for testing individual pagetest stories :)
[10:04] <bradb> BjornT: https://chinstrap.ubuntu.com/~dsilvers/paste/fileQXuk4G.html
[10:05] <seb128> bradb: https://launchpad.net/malone/bugs/31506
[10:05] <Ubugtu> malone bug 31506 in malone "Remove "are you sure" page from subscriptions" [Wishlist,Unconfirmed]  
[10:05] <bradb> BjornT: it's pretty annoying, yeah
[10:05] <seb128> bradb: you should read the bugs so :p
[10:07] <bradb> But the triagers are meant to ensure timely response, and alert me of any critical issues while I ignore bugmail.
[10:07] <BjornT> i'm mostly concerned with that the time it takes to run 'python test.py -f canonical.launchpad' almost doubled for me :(
[10:08] <bradb> BjornT: Wow. I usually run the tests with pqm. (So yes, I usually wait until it's reviewer stamped, to save time.)
[10:08] <seb128> bradb: do you get that many bugs?
[10:09] <seb128> bradb: I got 847 mails for launchpad since monday and I think I read almost all of them ...
[10:09] <bradb> seb128: Since Jan 20th, my bugmail folder has 2500 mails. Not all are Malone-specific, of course.
[10:09] <seb128> replying or fixing is another topic :)
[10:09] <seb128> bradb: 4295 since jan 20th :p
[10:10] <bradb> seb128: Try confining your bugmail reading to within Normal Working Hours :P
[10:10] <seb128> anyway that's not the topic, I do think you should read them even if you don't reply, that's the best way to know what issues people have around
[10:10] <bradb> yeah
[10:11] <seb128> bradb: no way to do that, I usually use saturday,sunday afternoon without IRC to catchup
[10:11] <bradb> exactly
[10:11] <seb128> which I agree should not be required
[10:11] <seb128> and I would not ask somebody else to do the same :)
[10:11] <lifeless> BjornT: due to the db isolation ?
[10:11] <lifeless> BjornT: yes, that patch should not be reverted. There was a bug open on the fact that they were /not/ isolated.
[10:12] <seb128> bradb: anyway, I've noted, better to let you know on IRC what bothers me so :)
[10:12] <seb128> (I already sort of do that ...)
[10:13] <BjornT> lifeless: i would guess so. i compared running tests on a fresh rocketfuel, and on a rocketfuel with r3146 and r3131 reverted.
[10:13] <bradb> thanks. i'll aim to clear out my bugmail folder next week though too. it's getting pretty crazy.
[10:13] <seb128> bradb: dholbach speaks about "mail terror" from launchpad now :)
[10:14] <seb128> he had like 1800 bug mails not read this morning he was trying to catchup a bit today
[10:14] <BjornT> lifeless: sure, it shouldn't be reverted. but something should be done to make it faster to run the tests.
[10:14] <bradb> seb128: whoa
[10:14] <seb128> bradb: how is the "stop sending 5 mails when somebody edits a bug" placed on the "to fix" list?
[10:15] <seb128> (which is a side effect of the: "you have to use 5 different pages to edit a bug")
[10:15] <bradb> seb128: Still a while to go on that one, I think. Mainly to convince the appropriate people (i.e. person) that five different pages to edit a bug sucks.
[10:16] <seb128> not easy person to convince ... :)
[10:16] <dilys> Merge to devel/launchpad/: Re-applying patch 4845 as I inadvertently reversed it while merging patch 31872 r=bjornt (r3196: Diogo Matsubara)
[10:16] <bradb> Mind you, kiko sent something to Mark a couple days ago talking about prioritizing changing status on the bug page, so maybe it's not /that/ far off. (Like, say, within a month.)
[10:18] <bradb> That kind of change would kill a few birds with one stone: reduced bugspam, faster triage, less annoyance, etc.
[10:20] <mpt> Keybuk, add your name to the BugWorkflow spec if you like it
[10:20] <mpt> it makes subscribing/unsubscribing a checkbox, with no extra page
[10:20] <seb128> bradb: right, would be nice
[10:20] <lifeless> BjornT: well during the dev cycle you almost certainly want to be running only malone tests for instance
[10:21] <lifeless> BjornT: so performance is important, but we're so far out of the 'instant gratification' zone at the moment, I think the time here isn't all tht important compared to isolation.
[10:23] <BjornT> lifeless: how do i run only malone test? and i do think time is somewhat important. previously it took less than 15 minutes to run, it was ok, i could run them during a workrave, and while reading some email or looking and looking at the diff.
[10:24] <BjornT> lifeless: now it takes 25 minutes, and that makes it a lot harder to find time to run them.
[10:25] <lifeless> BjornT: give me an example malone story or standalone name
[10:25] <lifeless> spiv: I think we need to do that zope 'when I say search in the test name I mean the whole path fix'
[10:26] <lifeless> BjornT: I understand. 15 minutes is 14 minutes too long IMO ;0
[10:27] <lifeless> BjornT: bzr runs 1500 tests in 3ish minutes. which is getting a bit slow.
[10:30] <BjornT> lifeless: oh, you mean only one pagetest story. i actually seldom have the need to run a single story. when i develop i mostly some doc/foo.txt. when i'm done i run all functional tests to see whether anything broke due to my changes.
[10:31] <lifeless> BjornT: I meant all tests with malone in the name actually, but the zope runner is rather borked.
[10:32] <lifeless> BjornT: it decides it knows more about the meaning of test python paths than we do.
[10:33] <BjornT> lifeless: well, quite often i do changes that can affect more than malone, so i need to run all tests. but sure quite often it's enough to run only part of the test, but with the current structure it's quite impossible.
[10:34] <lifeless> BjornT: yeah. best you can do is a path prefix like test.py -f lib.canonical.launchpad.doc
[10:34] <BjornT> we should probably work on grouping the standalone tests, so that tests that are related to each other are in the same story
[10:34] <lifeless> that would reduce the spurious setup time
[10:34] <lifeless> myself, I'd like us to stop testing postgresql, we know it works ;)
[10:36] <BjornT> yeah, that's true :) although iirc, not using a proper db for testing SQLObject is quite hard, it requires a lot of work to get it to work using stub classes
[10:36] <BjornT> it would be great if you got it to work though :)
[10:37] <BjornT> bradb: tell me about the changes to MilestoneVocabulary, why is it necessary?
[10:38] <bradb> BjornT: because of showing the milestone widget on the people pages. we have to show all the milestones on those pages.
[10:39] <bradb> it's a crap UI, tbh, but it's the best thing I can think of for an urgent fix, without getting overly complicated and clever trying funky heuristics on the Bug and BugTask tables to "guess" what milestones the user wants to choose from
[10:45] <mpt_> bradb, the batxhed notification (bug 1350) could be implemented independently of any merging of bug pages.
[10:45] <Ubugtu> malone bug 1350 in malone "Change notifications should be batched" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/1350
[10:45] <cprov> guys, see you tomorrow
[10:45] <bradb> mpt_: It's a lot more work though too.
[10:46] <mpt_> true
[10:48] <BjornT> bradb: hmm, is there really a need to search by milestone on the person pages?
[10:48] <bradb> BjornT: An urgent need, yeah.
[10:49] <BjornT> bradb: really, what is the use case? why can't they search in a context?
[10:49] <mpt_> BjornT, I thought that was what kiko suggested Kamion do earlier
[10:50] <BjornT> wasn't that searching for milestones for a distribution?
[10:50] <bradb> BjornT: That would require them knowing that they're supposed to switch to the context +bugs, for one. Ubuntu devs tend to drive Malone from their FOAF pages.
[10:52] <bradb> There's no logical reason for them /not/ to be allowed to search by milestone on their personal reports, other than that "it's harder to implement", which is usually an excuse reserved for only the most painful UIs.
[10:53] <BjornT> bradb: ok, i guess it's ok for now. i do think that the comment you added deserves to be an XXX. and don't you think it would be wise to use shortlist, so that we get a warning when the number of milestones get too high, so that we are forced to do something about it?
[10:54] <bradb> BjornT: Oh, right, for some reason I thought shortlist raised an exception.
[10:54] <bradb> A warning would be useful.
[10:55] <BjornT> ok, fix those two things and you can merge
[10:56] <bradb> great, thanks for taking some time out of your friday evening to look at it
[10:58] <mpt_> oh
[10:58] <mpt_> Different things have different sets of milestones
[10:58] <mpt_> and people can be assigned to bugs in different things
[10:58] <mpt_> So what milestones do you offer on a person's bugs page...
[10:59] <bradb> yeah, like i say, clever heuristics == pain
[10:59] <bradb> right now, i just put them all in there, so they can at least do their job
[10:59] <mpt_> All milestones for all distributions and products in Launchpad?
[11:00] <bradb> this problem is much deeper than just milestones. e.g. a bug never disappears from a user's subscribed bugs report until it's fixed in all contexts.
[11:00] <bradb> mpt_: yeah
[11:00] <bradb> so, it'll say "Ubuntu: dapper", or "bzr: 1.0", etc, in the list
[11:00] <bradb> like i say, crap UI, but I can't think of anything better that can land within the next 15-30 mins
[11:03] <matsubara> See you guys on wednesday. Here I go to Carnival! Take care.
[11:14] <jblack> I don't see a link on https://lists.ubuntu.com/mailman/listinfo/ for lp-devel. Do we have an archive?
[11:15] <elmo> lists.canonical.com
[11:16] <elmo> or just append 'launchpad/'
[11:17] <jblack> thanks\
[11:20] <dilys> Merge to devel/launchpad/: Fix https://launchpad.net/products/malone/+bug/5757 (OOPS: requesting an upstream fix doesn't check input for duplicates) r=kiko (r3197: Diogo Matsubara)