Patching SeaMonkey for Dummies? (bug 11054 - prune thread)
Rich Gray
https://bugzilla.mozilla.org/show_bug.cgi?id=11054
"Ignore (kill) a Subthread (branch: not the whole thread) (Troll)"
to SeaMonkey. I do have a working local trunk build as of
Sept. 1st.
I did some casual searching, but didn't come up with any
answers to these very basic, logistical questions:
* How do you organize modified and original files?
If I'm modifying a file in the tree, are there
techniques for local versioning, diff'ing etc.
* How does on apply a canned patch from a bugzilla bug?
Again, the versioning questions from above. I'm
guessing this involves the patch command...
* I understand the SM mailnews files are in a
different source directory than those of the patch.
What's the best way to do this? Just edit
the patch file to the new location? (I'm
assuming the files are the same, just moved.)
Is there a good 'organizing your patches' web page
somewhere?
I certainly look forward to seeing this enhancement
committed for SeaMonkey2. It will be a major newsreader
improvement. :) Would I be correct in assuming that it
will take a new bug to port this to SM, or can that happen
on 11054?
--
Rich (Pull thorn from address to e-mail me.)
SeaMonkey - Surfing the net has never been so suite!
Tony Mechelynck
That's a "Core" bug. As soon as it lands, it will (IIUC) appear simultaneously
in Tb3 and Sm2, and in any CVS "head" pull for mailnews or suite after the
landing date.
Best regards,
Tony.
--
ARTHUR: I've said I'm sorry about the old woman, but from the behind you
looked ...
DENNIS: What I object to is that you automatically treat me like an inferior...
ARTHUR: Well ... I AM king.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Justin Wood (Callek)
> Rich Gray wrote:
>> I'd like to try out applying
>> https://bugzilla.mozilla.org/show_bug.cgi?id=11054
>> "Ignore (kill) a Subthread (branch: not the whole thread) (Troll)"
>> to SeaMonkey. I do have a working local trunk build as of
>> Sept. 1st.
>>
>
> That's a "Core" bug. As soon as it lands, it will (IIUC) appear
> simultaneously in Tb3 and Sm2, and in any CVS "head" pull for mailnews
> or suite after the landing date.
>
Partly wrong. While the bug is in fact a "Core" Bug, its only UI
enhancements are done for TB Only "mail" subdirectory in the diff. The
Core changes are in the "mailnews" subdirectory in that diff, which
would then need to be exposed to our UI.
While I don't have the skills to *explain* how to port this patch, it
definately would be a good one to port.
IMHO, opening a new bug in the SeaMonkey (suite) product space in
bugzilla would be good for that, but mark the bug you cited as
"blocking" our bug. As we can't "land" our version to the codebase
until after the one you see actually "lands". And you really can't work
on this bug for Seamonkey well until after you at least patch your
mailnews stuff with the diff in that bug either.
/me hopes someone can explain this all or point him to a doc doing that.
~Justin Wood (Callek)
Justin Wood (Callek)
...actually *I* think I am wrong slightly...
It appears that the mailnews UI may not have made it into the suite/ dir
structure yet, unless I am seriously missing something. and it does
appear that the suite UI may have been touched by that diff.
Philip Chee
> ...actually *I* think I am wrong slightly...
> It appears that the mailnews UI may not have made it into the suite/ dir
> structure yet, unless I am seriously missing something. and it does
> appear that the suite UI may have been touched by that diff.
Correct. Notice that the patch modifies both versions of
mail3PaneWindowCommands.js, etc. However I'm not sure if the Suite
version of hiddenWindow.js needs to be touched as well.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]A clean desk is a sign of a cluttered desk drawer.
* TagZilla 0.066.6
Andrew Schultz
> * How do you organize modified and original files?
> If I'm modifying a file in the tree, are there
> techniques for local versioning, diff'ing etc.
Typically, you just keep the modified versions. I think patch might
keep backups. But the "original" is always in CVS, so you don't really
have to worry. If you screw it up, you can always just go back to CVS.
> * How does on apply a canned patch from a bugzilla bug?
> Again, the versioning questions from above. I'm
> guessing this involves the patch command...
For that patch, go to the top-level source directory (mozilla/) and do
patch -p0 < patchfile
Assuming you haven't pulled thunderbird sources, it will complain about
missing files from mail/. You can safely ignore those (just tell patch
to forge ahead). Or make your own patch file that includes everything
from the original except for mail/ changes.
> * I understand the SM mailnews files are in a
> different source directory than those of the patch.
> What's the best way to do this? Just edit
> the patch file to the new location? (I'm
> assuming the files are the same, just moved.)
If parts of the patch modify thunderbird files and don't update SM files
accordingly, the best way is generally to find the SM file and do the
modification by hand. If there's a big chunk added, you could
copy/paste it.
> Is there a good 'organizing your patches' web page
> somewhere?
Not that I know of.
> I certainly look forward to seeing this enhancement
> committed for SeaMonkey2. It will be a major newsreader
> improvement. :) Would I be correct in assuming that it
> will take a new bug to port this to SM, or can that happen
> on 11054?
Depends on how much change would be needed on the SM end and how much
time it would take. It it's just a small quick change, piggy-backing on
the existing bug would be OK. If it's more involved, then it's usually
best to let the first bug get resolved and continue discussion and work
in another bug.
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Steve Wendt
> Typically, you just keep the modified versions. I think patch might
> keep backups.
If you call "patch -R" keeping a backup. ;)
Andrew Schultz
heh. well, there's that. :)
But I also get foo.cpp.orig files littering my tree, which I assume come
from patch. Perhaps those are from failed patch attempts or
something... the patch man page supports that theory. There's also the
-b option that always makes backups.
Steve Wendt
> But I also get foo.cpp.orig files littering my tree, which I assume come
> from patch. Perhaps those are from failed patch attempts or
> something...
Right, there's usually *.rej files that go with them.
Neil
>I'm not sure if the Suite version of hiddenWindow.js needs to be touched as well.
>
>
No, it's not needed in this case; hiddenWindow.js is used on the Mac
when all the other windows have been closed, and we show a minimalist
version of the navigator window in that case, so we only need to change
hiddenWindow.js to match navigator changes.
--
Warning: May contain traces of nuts.
Robert Kaiser
> It appears that the mailnews UI may not have made it into the suite/ dir
> structure yet, unless I am seriously missing something.
Yes, that's https://bugzilla.mozilla.org/show_bug.cgi?id=367034
Robert Kaiser
Rich Gray
So basically, if a file exists in suite/, I should edit the patch
file to change it instead.
I don't see the new .jpg files sourced in the patch anywhere...
[forth attempt to reply, coming back to 1.1.4 for this one...]
Rich Gray
So basically, if a file exists in suite/, I should edit the patch
file to change it instead.
I don't see the new .jpg files sourced in the patch anywhere...
--
Rich Gray
So basically, if a file exists in suite/, I should edit the patch
file to change it instead.
I don't see the new .jpg files sourced in the patch anywhere...
--
Rich Gray
So basically, if a file exists in suite/, I should edit the patch
file to change it instead.
I don't see the new .jpg files sourced in the patch anywhere...
--
Neil
> [retransmit - first attempt an hour ago got lost??]
Weird, looks like your fourth attempt got here first for some reason.
Rich Gray
> Rich Gray wrote:
>
>> [retransmit - first attempt an hour ago got lost??]
>
> Weird, looks like your fourth attempt got here first for some reason.
>
not sending. I was able to go over to mozilla.test and post and reply to
the post very quickly. I then did the fourth try from 1.1.4 which showed
up promptly. A little while later, the previous attempts showed up. I
can't see how SM2 could hold them, so I *guess* it was some sort of news
server glitch.
My question about the jpg's in the patch remains. ARE they in the patch??
I would expect to see multiple jpg files, but I only see the one composite.
https://bugzilla.mozilla.org/attachment.cgi?id=279000 This seems like it
is for human consumption, not the individual image files I'd expect to see.
Since pulling the nightly on Sept 1st and also doing a build that same
day, I've encountered enough glitches that I want to come current.
- shortcut keystrokes not working (cut/paste/mark all read)
- a window close problem which appears to be mac only
- browser just got goofy after a few days, not loading things right
(clicked links ignored, images not loaded... :/ )
Before chasing any of these, I want to refresh. My intent is to pull
the current nightly binary, see if it runs without anything ugly and if
ok, rebuild my local build. But this makes more newbie quesitons:
Once I patch my source tree, how do I refresh it against changes that
are being made on trunk? Do I just refresh the file, coming back into
sync with trunk then reapply the patches? (commands please!) Any other
patch/cvs suggestions?
Thanks!
Andrew Schultz
> Once I patch my source tree, how do I refresh it against changes that
> are being made on trunk? Do I just refresh the file, coming back into
go to the top-level source directory and do
gmake -f client.mk checkout
(just like you did to start with)
Files that have been updated that you didn't modify will update
normally. File that have been updated and you did modify will be merged
by CVS. All will go well so long as you changed a different part of the
file. If you changed a part of the file that was changed in CVS, it
will print a message that it failed and it will list that file with a
"C" in its output (client.mk will re-print that line at the end of the
checkout).
--
Andrew Schultz
aj...@buffalo.edu
http://www.sens.buffalo.edu/~ajs42/
Robert Kaiser
> My question about the jpg's in the patch remains. ARE they in the patch??
> I would expect to see multiple jpg files, but I only see the one composite.
> https://bugzilla.mozilla.org/attachment.cgi?id=279000 This seems like it
> is for human consumption, not the individual image files I'd expect to see.
A patch can only contain code, i.e. text file changes, no binary files.
Having only a composite image is something quite usual in Mozilla
chrome, it saves us the time of opening and decoding multiple files.
There is an internal -moz-image-region CSS property that allows us to
select which area of the composite image is actually shown on an element.
Robert Kaiser
Neil
Although that particular case doesn't look typical, having three images
in a three-quarter square.