#instantbird log on 12 29 2013

All times are UTC.

00:00:02 <flo-retina> especially as there are 21 of them!!!
00:01:12 <-- dew has quit (Ping timeout)
00:01:32 <flo-retina> for "Slicing error: bug[target_milestone] is 0.2a1, not 0.2" I suspect what happened is we started with a tm of "0.2", then decided to do an alpha, and renamed the existing 0.2 into 0.2a1 and then created a new 0.2
00:01:37 <flo-retina> which makes a very confusing history :-/
00:02:26 --> dew has joined #instantbird
00:02:31 <flo-retina> I have 8 of these errors, for 10 bugs with the 0.2a1 tm
00:02:47 <flo-retina> that's possible, it would mean 2 bugs have had there milestone set to 0.2a1 after it was renamed
00:03:34 <flo-retina> see bug 2. The tm is 0.2a1, but the history says we set it to "0.2"
00:03:36 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2 nor, --, 0.2a1, florian, RESO FIXED, Load accounts even when the prpl can't be loaded
00:04:27 <flo-retina> anybody's got time to look at these 10 bugs and tell me which are the 8 of them that have had their TM set to 0.2? https://bugzilla.instantbird.org/buglist.cgi?quicksearch=FIXED%20milestone%3A0.2a1&list_id=6279
00:04:43 <flo-retina> (give me the list as a JS array ;))
00:05:48 <aleth> less than 8 of them have 0.2 as TM
00:06:07 <flo-retina> that's strange
00:06:13 <aleth> or do you mean in the history?
00:06:16 * aleth is confused
00:06:22 <flo-retina> they all have 0.2a1 displayed in the bug
00:06:31 <flo-retina> but I expect 8 out of the 10 have it set to 0.2 in the history
00:06:53 <flo-retina> and it "magically" goes from 0.2 to 0.2a1 without this change being visible in the history
00:07:11 <aleth> https://bugzilla.instantbird.org/show_activity.cgi?id=113 has no TM info in the history at all
00:07:51 <flo-retina> then the TM was set when filing the bug
00:07:57 <flo-retina> and it's not one I care about :)
00:08:26 <aleth> bug 141 has the pattern you expected
00:08:28 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=141 min, --, 0.2a1, nobody, RESO FIXED, IRC /quit command should not display an error in account manager
00:09:27 <aleth> 192 does not
00:09:45 <aleth> so that's two ;)
00:10:56 <aleth> The other 8 will be the ones for your array...
00:10:59 <Mic-Linux> These have the tm set to 0.2: [2,57,79,158,141,171,170]
00:11:06 <flo-retina> the one where there's some funny business with the URL field is https://bugzilla.instantbird.org/show_activity.cgi?id=590
00:11:07 <Mic-Linux> These don't: [112,113,192]
00:11:46 <flo-retina> hmm, so that means there's one where it was set to 0.2, then renamed to 0.2a1, then set to something else :-/
00:12:45 <qheaden> Hello.
00:12:51 <Mic-Linux> Hi qheaden
00:12:51 <flo-retina> I wonder why that URL -> see also change causes any problem
00:12:54 <flo-retina> qheaden: hello :)
00:12:57 <qheaden> flo-retina: Are you importing some bugs into BMO?
00:13:16 <flo-retina> qheaden: that's a strange question, given that you sent us a password for that purpose ;)
00:13:16 <aleth> IMPORT ALL THE BUGS
00:13:17 <aleth> scnr
00:13:22 <qheaden> :)
00:13:35 <qheaden> flo-retina: I mean right at this moment?
00:13:40 <flo-retina> qheaden: no
00:13:43 <qheaden> Oh okay.
00:13:47 <flo-retina> qheaden: you can still make changes on BIO
00:13:52 <qheaden> Gotcha.
00:13:58 <qheaden> Are any of the Ib bugs visible on BMO yet?
00:14:02 <flo-retina> no
00:14:04 <aleth> qheaden: There are some test run results on landfill
00:14:06 <flo-retina> and please don't file any there
00:14:33 * qheaden believes that landfill should stay as a landfill. :P
00:14:41 <flo-retina> I'm hoping to launch another full test run on https://bugzilla-dev.allizom.org/ before going to bed
00:15:12 <flo-retina> qheaden: we've probably filed already at least 3,000 bogus bugs there, so yeah, there's quite a bit of junk in there ;)
00:15:19 <qheaden> :P
00:16:28 <-- dew has quit (Ping timeout)
00:17:16 --> dew has joined #instantbird
00:18:15 <flo-retina> rerunning with that list of bogus 0.2 bugs :)
00:18:59 <flo-retina> I still get 5 of these errors :-S
00:19:02 <flo-retina> (I had 8 before)
00:19:58 --> BWMerlin has joined #instantbird
00:20:44 <flo-retina> oops, the query shouldn't have said "Resolution: FIXED" :(
00:20:55 <flo-retina> the other one I found by looking at the logs is https://bugzilla.instantbird.org/show_bug.cgi?id=80
00:20:57 <instantbot> Bug 80 nor, --, 0.2a1, florian, RESO DUPLICATE, Exception when closing a conversation if the account was deleted
00:21:21 <flo-retina> bug 107
00:21:22 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=107 maj, --, 0.2a1, nobody, RESO DUPLICATE, IRC Commands do not work
00:21:49 <flo-retina> https://bugzilla.instantbird.org/show_activity.cgi?id=151 is a mess :(
00:22:03 <aleth> indeed
00:22:38 <flo-retina> 162 is another one
00:23:04 <flo-retina> https://bugzilla.instantbird.org/show_activity.cgi?id=169 is also a mess :(
00:26:16 <flo-retina> so I guess for these 2 I need to check the timestamp of the event to decide of the mapping
00:33:27 <-- Mic-Linux has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
00:34:22 <flo-retina> cool, no more target milestone problem :)
00:35:37 <-- dew has quit (Ping timeout)
00:36:23 <flo-retina> here is how the hack looks: http://hg.instantbird.org/bio-merge/rev/f61d51d52332#l1.37
00:36:26 --> dew has joined #instantbird
00:39:04 <flo-retina> so apparently the problems with the url field happen when someone emptied the URL field
00:39:26 <flo-retina> it seems that "field hasn't been set" and "field has been set to an empty value" isn't fully equivalent
00:39:34 <flo-retina> shouldn't be too hard to workaround I guess
00:40:14 <aleth> hacks are ok in code that only has to work once ;)
00:40:20 <flo-retina> sure :)
00:40:48 <flo-retina> then I'll need to look into the 21 remaining errors = 21 missing attachments
00:41:12 <flo-retina> and after that... well, what's left on the todo pad :-/
00:41:30 <aleth> the utf8 thing is really annoying
00:41:36 <flo-retina> handling blocks/depends on is the big piece
00:41:42 <flo-retina> aleth: I'll just work around it
00:41:45 <aleth> let's hope it gets fixed soon
00:41:55 <flo-retina> I'm going to assume it won't
00:42:16 <flo-retina> if Gerv does something for us this week-end, I would prefer if it is adding the 5 milestones that we forgot to request
00:45:05 --> mconley has joined #instantbird
00:45:24 <-- dew has quit (Ping timeout)
00:45:24 <flo-retina> I guess I could do with some help on the "- Create the full map of email addresses" step
00:45:44 <flo-retina> for the people who sent us a password, we will use it
00:45:53 <flo-retina> for others, their changes will be replayed by instantbot
00:45:53 --> dew has joined #instantbird
00:46:18 <flo-retina> but even if we do their changes with instantbot, if we know their BMO email, we can add them to the cc list if they were in the BIO cc list
00:46:28 <flo-retina> or set them as assignee
00:47:15 <-- aleth has quit (Quit: exit stage left)
01:01:26 <-- mconley has quit (Input/output error)
01:07:36 <-- dew has quit (Ping timeout)
01:08:20 --> dew has joined #instantbird
01:13:01 <-- dew has quit (Connection reset by peer)
01:14:47 --> dew has joined #instantbird
01:26:09 <-- dew has quit (Ping timeout)
01:27:08 --> dew has joined #instantbird
01:29:43 <-- dew has quit (Ping timeout)
01:30:20 --> dew has joined #instantbird
01:36:28 <-- dew has quit (Ping timeout)
01:36:47 --> dew has joined #instantbird
01:40:06 <-- rosonline has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
01:48:13 <flo-retina> interestingly, the 21 errors weren't directly related to the 21 missing attachments
01:48:34 <flo-retina> some of the errors were just noise; when the code was doing the right thing already
01:48:50 <flo-retina> it was just something to be expected rather than an error
02:43:41 <flo-retina> actually, I had 21 errors when trying to flag missing attachments, but only 11 missing attachments (some were flagged multiple times)
03:30:13 <flo-retina> we've got 48 events that have encoding problems
03:30:39 <-- wnayes has quit (Quit: wnayes)
04:03:48 <instant-buildbot> build #1064 of linux-nightly-default is complete: Success [3build successful]  Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/1064
05:04:32 <flo-retina> so the encoding issue was hiding something else: BzAPI does 'flag' requests using the GET method, not POST. So when the comment is over a certain length, the request fails with "URI too long", even if the encoding is correct.
05:11:01 <flo-retina> all known errors from the previous full test run are fixed! \o/
05:11:13 <flo-retina> now I need to look at the blocks/depends_on fields
05:23:18 --> nhnt11 has joined #instantbird
05:33:14 --> mconley has joined #instantbird
05:37:50 <instant-buildbot> build #1512 of macosx-nightly-default is complete: Success [3build successful]  Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/1512
05:44:02 <-- mconley has quit (Connection reset by peer)
05:44:19 --> mconley has joined #instantbird
05:44:28 <-- nhnt11 has quit (Ping timeout)
06:18:11 <-- mconley has quit (Input/output error)
06:20:36 --> nhnt11 has joined #instantbird
07:26:07 <flo-retina> bug dependencies work: https://landfill.bugzilla.org/bzapi_sandbox/show_activity.cgi?id=14506 ! :)
07:39:54 <instant-buildbot> build #1214 of win32-nightly-default is complete: Success [3build successful]  Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1214
08:19:32 --> mconley has joined #instantbird
08:25:43 <-- mconley has quit (Ping timeout)
08:57:27 <-- gerard-majax_ has quit (Quit: Ex-Chat)
08:57:33 --> gerard-majax__ has joined #instantbird
09:15:41 <flo-retina> I started a test import at https://bugzilla-dev.allizom.org/show_bug.cgi?id=916780
09:16:02 <flo-retina> Unless I notice it's completely broken in the next few minutes, I'll go to bed, and assume it will run for 13+ hours.
09:32:29 --> hadi has joined #instantbird
09:35:41 <-- gerard-majax__ has quit (Connection reset by peer)
09:35:47 --> gerard-majax_ has joined #instantbird
09:45:36 --> Even has joined #instantbird
09:45:36 * ChanServ sets mode +o Even 
09:51:42 --> igorko has joined #instantbird
09:54:13 --> jb has joined #instantbird
10:08:28 <-- jb has quit (Ping timeout)
10:17:02 <-- igorko has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
10:20:09 <-- EionRobb has quit (Quit: Leaving.)
11:28:00 --> aleth has joined #instantbird
11:28:00 * ChanServ sets mode +h aleth 
12:05:20 <-- aleth has quit (Ping timeout)
12:40:00 --> aleth has joined #instantbird
12:40:00 * ChanServ sets mode +h aleth 
13:02:40 <-- aleth has quit (Ping timeout)
13:20:20 <-- nhnt11 has quit (Ping timeout)
13:21:39 --> nhnt11 has joined #instantbird
13:46:23 <flo-linux> most of the errros so far are ""There is no component named 'www.instantbird.org' in the 'Instantbird Servers' product."", which just means I forgot one line in the component mapping
14:14:27 <-- hadi has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
14:14:44 --> hadi has joined #instantbird
14:45:40 --> unghost has joined #instantbird
15:25:05 --> aleth has joined #instantbird
15:25:05 * ChanServ sets mode +h aleth 
15:36:03 <-- aleth has quit (Ping timeout)
15:43:51 --> aleth has joined #instantbird
15:43:51 * ChanServ sets mode +h aleth 
16:23:28 <-- aleth has quit (Ping timeout)
16:29:15 --> aleth has joined #instantbird
16:29:16 * ChanServ sets mode +h aleth 
16:29:25 --> Mic has joined #instantbird
16:29:32 * Mic is now known as Mic2
16:40:27 <-- Mic2 has quit (Ping timeout)
16:40:31 --> Mic2 has joined #instantbird
16:54:39 --> wnayes has joined #instantbird
16:55:53 <flo-retina> unless we discover something awfully broken, the real import is likely going to happen next night
16:56:55 <-- aleth has quit (Ping timeout)
17:02:45 <Mic2> It will take ages to memorize all bug numbers again...
17:04:33 <Mic2> (that was only fun - just to make sure nobody takes that serious;)
17:16:11 <flo-retina> Mic2: I was shocked to see that I knew the bug number of JS-IRC yesterday
17:16:24 <flo-retina> I was looking for it to test my work on bug dependencies
17:16:40 <flo-retina> I started querying BIO and gmail (my bugmail), but couldn't find it quickly
17:16:51 <flo-retina> then I typed 'randomly' 507 and that was it!
17:41:48 --> jb has joined #instantbird
17:46:59 <-- Mic2 has quit (Quit: Mic2)
17:47:08 <-- jb has quit (Ping timeout)
17:56:42 <-- BWMerlin has quit (Quit: BWMerlin)
19:02:23 <-- Suiseiseki has quit (Ping timeout)
19:03:56 <-- nhnt11 has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com)
19:21:14 --> Suiseiseki has joined #instantbird
19:33:50 --> mconley has joined #instantbird
19:42:05 <-- unghost has quit (Quit: Ухожу я от вас (xchat 2.4.5 или старше))
19:44:13 --> Mic has joined #instantbird
19:44:32 * Mic is now known as Mic2
21:09:28 --> jb has joined #instantbird
21:18:20 --> EionRobb has joined #instantbird
21:21:25 <-- dew has quit (Ping timeout)
21:22:23 --> dew has joined #instantbird
21:37:57 <-- dew has quit (Ping timeout)
21:43:51 <-- jb has quit (Ping timeout)
21:51:32 <flo-retina> Initially I wanted to the import script to stop immediately if a request fails
21:51:57 <flo-retina> but I'm more and more leaning toward letting it continue, and just replay by hand the few events that will have failed randomly
21:52:37 --> dew has joined #instantbird
21:52:44 <Mic2> Does that work or will that mess up things with the order of events?
21:52:49 <Mic2> *might that
21:53:00 <flo-retina> both? :)
21:53:10 <flo-retina> I guess it depends what fails
22:06:48 <-- hadi has quit (Ping timeout)
22:07:08 --> hadi has joined #instantbird
22:08:39 <qheaden> Hello
22:09:18 <qheaden> flo-retina: I just changed the password for BMO, so things should work.
22:10:24 <flo-retina> qheaden: awesome, thanks! :)
22:10:58 <qheaden> Np. Sorry for that delay. 
22:11:15 <qheaden> So when will the import start? 
22:11:30 <flo-retina> 2-3 hours from now seems likely.
22:11:44 <qheaden> Ok
22:11:50 <flo-retina> the test import on bugzilla-dev seems almost finished (13 bugs left to import)
22:12:04 <flo-retina> I would like us (if some people are still around) to spend some time looking at it to see if there are obvious defects
22:12:13 <flo-retina> I will also inspect the log of the import script
22:12:24 <flo-retina> and then close BIO, and redownload its content, including the latest changes.
22:12:29 <qheaden> Of the official import? 
22:12:48 <flo-retina> I don't understand the question
22:13:45 <qheaden> You want us to observe the bugzilla-dev import or the official?
22:14:34 <flo-retina> the bugzilla-dev
22:14:48 <flo-retina> you will have as much time as you want to inspect the final one, but it will be too late to make changes
22:14:49 <qheaden> Oh ok. 
22:15:03 * qheaden is outside right now.
22:15:24 <flo-retina> I'm not sure who is around
22:15:33 <flo-retina> finished!
22:15:37 <flo-retina> 781 minutes
22:15:48 <flo-retina> 13hours
22:15:51 <flo-retina> that's consistent
22:16:09 <flo-linux> "// done. Replayed 20903 events. 141 errors."
22:16:10 <qheaden> What is the link to bugzilla-dev?
22:16:59 <flo-retina> qheaden: from  https://bugzilla-dev.allizom.org/show_bug.cgi?id=916780 to  https://bugzilla-dev.allizom.org/show_bug.cgi?id=919034
22:17:19 <qheaden> Ok
22:17:22 <flo-retina> I guess you can look at the JS-Yahoo bug
22:17:40 <flo-retina> that's hairy one, and you know it more than anybody else, so you are more likely to notice if something is wrong on it
22:19:51 <qheaden> Are you able to send a link? I'm on my phone and navigation is a bit annoying. 
22:20:10 <flo-retina> what's the bio number?
22:20:53 <qheaden> 1982
22:22:05 <flo-retina> qheaden: https://bugzilla-dev.allizom.org/show_bug.cgi?id=918731
22:22:12 <qheaden> Thanks
22:22:37 <flo-retina> you may want to login to see more things
22:22:41 * qheaden is about to drive home
22:22:47 <flo-retina> (your password is your temporary BMO one)
22:22:59 <flo-retina> qheaden: you don't have to look at it _immediately_
22:23:05 <qheaden> I will be on in a few minutes. 
22:23:06 * flo-retina doesn't know how far from home qheaden is
22:45:38 <flo-linux> my macbook is horribly slow, the process SystemUIServer (I guess the mac equivalent of the X server) is sucking 20% of CPU, I guess it isn't responsive
22:47:15 <flo-retina> hmm, looks like closing iTunes 'fixed' it :-S
22:53:22 <flo-retina> the error about the 0.1.5 target milestone seems reasonable: https://bugzilla.instantbird.org/show_activity.cgi?id=149
22:54:17 <flo-retina> I'm very tempted to just remove that history entry from the bug's downloaded file
22:55:53 <flo-retina> hmm, I guess I can just skip it in the script
22:57:46 <flo-retina> hmm, or just map it to 0.2a1
22:57:53 <flo-retina> that's probably what 0.1.5 has been renamed into
23:01:27 <-- Tonnes has quit (Ping timeout)
23:01:58 <flo-retina> Mic2 (and others who may be reading) : how do you feel about https://bugzilla-dev.allizom.org/show_bug.cgi?id=917270#c5 ?
23:02:25 --> Tonnes has joined #instantbird
23:02:30 <flo-retina> I'm wondering if we should add another line of auto-generated text explaining that this comment didn't exist in BIO, and that the next comment numbers will be off
23:04:11 <flo-retina> "*** No comment included in the original change, next comment numbers will have an offset ***"?
23:05:38 <-- qlum has quit (Ping timeout)
23:06:27 <-- Tonnes has quit (Ping timeout)
23:07:49 --> qlum has joined #instantbird
23:08:18 --> Tonnes has joined #instantbird
23:08:47 --> aleth has joined #instantbird
23:08:47 * ChanServ sets mode +h aleth 
23:09:24 <Mic2> I think pointing out that there's a change in the comment numbers would be nice.
23:09:45 <Mic2> This way people would at least know that this kind of thing could happen...
23:10:16 <flo-retina> I think it would be confusing to point it out in some cases (we already do) and not others
23:10:23 <flo-retina> any idea of what the right wording could be?
23:10:30 <flo-retina> the shorter the better ;)
23:10:36 <flo-retina> aleth may also have ideas :)
23:11:39 <-- Tonnes has quit (Connection reset by peer)
23:11:39 <-- qlum has quit (Ping timeout)
23:13:22 --> qlum has joined #instantbird
23:14:40 <aleth> I was a little confused by "original change" as it's a new attachment, not a "change" (the change is of the bug)
23:15:27 --> Tonnes has joined #instantbird
23:18:03 <flo-retina> aleth: is it?
23:18:14 <flo-retina> which comment are you looking at exactly?
23:18:16 <aleth> How about "Attmnt 526 originally attached to bio 507 at (date) without a comment (subsequent comment numbers may be shifted)"
23:18:38 <hadi> hm
23:18:43 <flo-retina> aleth: I think there's some confusion here. Attaching without a comment isn't possible at all.
23:18:57 <aleth> I'm certainly confused.
23:19:01 <flo-retina> aleth: the *change* I was talking about is marking an attachment obsolete, or setting a flag
23:19:24 <aleth> Maybe that should be more explicit.
23:19:37 <flo-retina> can you link me to what you are looking at?
23:20:02 <aleth> https://bugzilla-dev.allizom.org/show_bug.cgi?id=917270#c5
23:20:51 <flo-retina> aleth: you will better understand what's going on if you login
23:21:15 <flo-retina> if you login you'll see the line saying "Attachment #805568 - Attachment is obsolete: true" grouped with that comment
23:21:41 <flo-retina> (password for your account there is the temporary BMO password you emailed me)
23:21:53 <aleth> OK, if that's there I guess it makes sense the way it is
23:22:23 <flo-retina> what I was discussing with Mic is adding another line of auto-generated text, explaining that comment numbers will be off
23:22:28 <flo-retina> and I wasn't sure how I could best phrase that
23:22:50 <aleth> The bit in brackets I posted earlier is quite short
23:23:17 <flo-retina> which one is this?
23:24:03 <aleth> "... without a comment (subsequent comment numbers may be shifted)"
23:24:57 <aleth> or better "any subsequent comment numbers will be shifted"
23:26:22 <flo-retina> so you would remove the "***" at the end of the first line, and just continue the same sentence?
23:27:03 <aleth> yes, I'd add "without a comment" to the same sentence
23:27:50 * flo-retina has filed more bugs in a week than in his entire life
23:28:02 <aleth> :D
23:28:09 <-- EionRobb has quit (Quit: Leaving.)
23:28:31 <flo-retina> I just tweaked the script a bit to add this comment when resolving the bug: https://bugzilla-dev.allizom.org/show_bug.cgi?id=919040#c2
23:28:48 <aleth> You can now measure your productivity in bugs per hour ;)
23:28:48 <flo-retina> we decided to not include it for when only some fields have been updated (eg the whiteboard)
23:28:59 <flo-retina> aleth: ahah :)
23:29:13 <flo-retina> aleth: well, it takes me 13 hours to file 2,2k bugs
23:29:28 <flo-retina> _and_ fix a significant number of them! :)
23:29:56 <aleth> That's why they're Instantbugs.
23:30:51 <aleth> That resolving comment looks good to me.
23:31:39 <flo-retina> aleth: here is how it looks: https://bugzilla-dev.allizom.org/show_bug.cgi?id=919041#c2
23:32:25 <aleth> Hmm, maybe it should be s/any/so
23:32:45 <flo-retina> I was wondering if we should s/without a comment/without comment/
23:33:25 <aleth> It's shorter, so that seems good
23:34:18 <flo-retina> I dislike the "post" word which seems wrong for a change without comment
23:34:59 <aleth> You could use "change" or "modification" there too?
23:35:26 <flo-retina> I was thinking of making it "change", yes
23:35:41 <flo-retina> the logic is getting a bit complicated in the code, but I don't really mind, as long as I don't completely mess it up :)
23:38:57 <flo-retina> aleth: https://bugzilla-dev.allizom.org/show_bug.cgi?id=919042#c2
23:39:02 <flo-retina> is this ready?
23:40:08 <aleth> s/without comment.../was without comment, so any subsequent comment numbers will be shifted
23:40:30 <aleth> would be better I think. (Third pair of eyes would be useful at this point ;) )
23:40:35 <aleth> qheaden ?
23:43:17 <-- aleth has quit (Ping timeout)
23:43:22 <flo-retina> how do I close BIO?
23:49:32 <-- Suiseiseki has quit (Client exited)
23:49:42 --> Suiseiseki has joined #instantbird
23:53:40 * qheaden gets home and finishes his dinner.
23:58:17 <flo-retina> final download started, any change made on BIO from now on won't be migrated.