554855 - Package nsMicrosummaryService.js in SeaMonkey

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Serge Gautherie (:sgautherie)]

(Windows debug build) Error console:
{
Failed to load XPCOM component: ...\components\nsMicrosummaryService.js
}

Comment 1

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Just package it [Checkin: Comment 13]

Comment 2

[Serge Gautherie (:sgautherie)]

Attachment: (Bv1-191) Support downgrading [Checkin: Comment 14]

Comment 3

[Robert Kaiser]

This is useless and unneeded as long as we don't ship places bookmarks. No idea where you got that error message as we just shouldn't care right now. If it's not there, it's not there, right?

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #3)

> No idea where you got that error message as we just shouldn't care right now.

"1269474729" tinderbox build.

> If it's not there, it's not there, right?

The error is there and in package-compare output too!

Comment 5

[Robert Kaiser]

(In reply to comment #4)
> (In reply to comment #3)
> 
> > No idea where you got that error message as we just shouldn't care right now.
> 
> "1269474729" tinderbox build.

Can't decipher that. Maybe I just don't have your brain that may be able to parse unix epoch and fill in missing clues on the fly. Also, as I said, SeaMonkey isn't using this anyhow at the moment. If there is a test failure, or something like that, this could be a reason, but you haven't given me any so far.

> > If it's not there, it's not there, right?
> 
> The error is there and in package-compare output too!

Well, seeing it there is nice but not forcing us to do anything, esp. as I have this packaging in my local patches for places bookmarks - where it actually will be used.

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)

> Can't decipher that.

(In reply to comment #0)
> (Windows debug build) Error console:
(In reply to comment #4)
> "1269474729" tinderbox build.

ftp://ftp.eu.mozilla.org/pub/seamonkey/tinderbox-builds/comm-central-trunk-win32-debug/1269474729

> Well, seeing it there is nice but not forcing us to do anything

I can't believe we're having the same argument over and over again:
anyway, just let me know when this is fixed ... then I'll look at the other error console outputs :-|

PS: And I'm not quoting you on your "one bug per one liner patch" complains.

Comment 7

[Robert Kaiser]

(In reply to comment #6)
> (In reply to comment #5)
> 
> > Can't decipher that.
> 
> (In reply to comment #0)
> > (Windows debug build) Error console:
> (In reply to comment #4)
> > "1269474729" tinderbox build.
> 
> ftp://ftp.eu.mozilla.org/pub/seamonkey/tinderbox-builds/comm-central-trunk-win32-debug/1269474729

That's not something that really helps me. I don't think we have any SeaMonkey code that calls this, so I still can't see why we need it.

> > Well, seeing it there is nice but not forcing us to do anything
> 
> I can't believe we're having the same argument over and over again:
> anyway, just let me know when this is fixed ... then I'll look at the other
> error console outputs :-|

It's just that I can't see what current code would need to package this and you would bitrot what I already have on disk and think we don't need before places bookmarks land.

> PS: And I'm not quoting you on your "one bug per one liner patch" complains.

I never said that. I said "one bug per issue that can be closed with a distinct patch or well-described set of patches". If such a patch is one line or 20,000 lines doesn't change that (though the 20,000 line patch should probably be split into a patch set).

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to comment #7)

> That's not something that really helps me.

I can't be more explicit about which build I used.

> you would bitrot what I already have on disk

Should be as simple as using "hg rebase".

Comment 9

[Robert Kaiser]

(In reply to comment #8)
> (In reply to comment #7)
> 
> > That's not something that really helps me.
> 
> I can't be more explicit about which build I used.

Sure, but that doesn't tell why there is an error at all. As I said, we should even be calling this anywhere yet.

Comment 10

[Serge Gautherie (:sgautherie)]

(In reply to comment #9)
> that doesn't tell why there is an error at all.

Because it's listed in components.list, I assume.

Comment 11

[Robert Kaiser]

(In reply to comment #10)
> (In reply to comment #9)
> > that doesn't tell why there is an error at all.
> 
> Because it's listed in components.list, I assume.

Oh, hmm, that could actually be a reason. The first possibly reasonable explanation for the patch that I hear in this bug. If you 1) could be somewhat sure that this is the case, and 2) would have said so right away, I would have gone for a straight r+ at the first look. Maybe the next time. ;-)

Now, if investigation can show that is it, I'm convinced as well. :)

Comment 12

[Robert Kaiser]

Comment on attachment 434801 [details] [diff] [review]
(Av1) Just package it
[Checkin: Comment 13]

bsmedberg says there may be indeed errors reported in that case because it's in components.list, so I'm giving you review for this. Would have been easier to have that reason right away, would have spared us a few discussions. ;-)

Comment 13

[Serge Gautherie (:sgautherie)]

Comment on attachment 434801 [details] [diff] [review]
(Av1) Just package it
[Checkin: Comment 13]


http://hg.mozilla.org/comm-central/rev/9e3c8ed5373b

Comment 14

[Serge Gautherie (:sgautherie)]

Comment on attachment 434803 [details] [diff] [review]
(Bv1-191) Support downgrading
[Checkin: Comment 14]


http://hg.mozilla.org/releases/comm-1.9.1/rev/c71da96d388d