There are two bugs here, which are distinct.  I think that we are
talking about the same thing, just in different ways.

The first bug I've encountered is a bug that I actually ran across
during the use of my python-capable xulrunner.  It does NOT have
anything to do with the pyxpcom.  Some sort of security issue with
chrome urls and XSLT translation.  Not immediately recognizing it as a
bug (but perhaps something boneheaded I was doing) I posted a question
to mozilla.dev.tech.xul.  A nice fellow named axel said "Hey!  That
sounds like a bug I saw awhile back.  I think it's fixed.  Checkout
the trunk, it's probably a nonissue now"

It had been weeks since I built the trunk, so I pulled a fresh copy
out of CVS, and built it, using the same mozconfig that I had used to
build it before.  This is when I encountered my second "bug" which is
really just a build failure.  THIS bug appears to be connected to
pyxpcom, or at least its suite of tests, because the failure occurs in
the following directory: extensions/python/dom/test/pyxultest

It was at this point I posted the question to you, and you responded,
which kicked me off on the idea of keeping the old stable pyxpcom
stuff, but checking out the bleeding-edge trunk.  That's actually a
pretty stupid idea, because I'm fair sure it's activity in the trunk
that broke the pyxul test thing (since as you said, that's not
actively developed)

I went back to the usenet group, to see if they had any ideas, and it
was at that time that axel said "hey, this is a legitimate bug, I
haven't seen it, file it in bugzilla"  I did so, and I guess he copied
it to you, since it seemed like it was in your territory.

https://bugzilla.mozilla.org/show_bug.cgi?id=392210

That's the link.  The tail of my build is there, so you can see what
I'm yammering about.

It seems to me that this pyxpcom test fixture is the victim of
something that got changed elsewhere, causing it to break.

Thanks for all your help!

-R

On 8/14/07, Mark Hammond <mhammond@[...].au>  wrote:
>  > Folks in another group cite this as a bug.
> 
>  You are saying that it appears that the trunk has a new bug that was not in
>  previous versions - but this bug is outside of pyxpcom, correct?
> 
>  >  I've filed it
>  > with bugzilla... apparently the python extension tests don't
>  > account for the BUILD_ID (which was previously globally
>  > defined, but maybe isn't now?  I don't totally understand,
>  > but the guy I spoke with seemed pretty confident.
> 
>  I don't understand this, or how it is relevant to your original problem (but
>  I may well be missing something)
> 
>  > I think the mixed checkout option is a good one.  I need the
>  > trunk for fixes to certain bugs in the main core, but for the
>  > python extensions, I can settle for an older stable build.
> 
>  No, I'm saying the reverse - that the *rest* of the trunk is likely to
>  develop bugs, and only once the main code moves to a branch is it likely to
>  be stable - hence, you are best off using a branch for the rest of the code.
> 
>  On the other hand, the fact that pyxpcom is not undergoing much change means
>  that you can stick with the trunk here - particularly if pyxpcom has
>  enhancements that are *not* on the branch you are using for the rest of the
>  code - the way to use such enhancements is to use pyxpcom from the trunk (or
>  a later branch), while the rest of the tree remains on a stable, but older
>  branch
> 
>  I fear we are talking about quite different things :)  Do you have any
>  reason to believe the original problem you mailed about has anything to do
>  with pyxpcom?  To my eyes it seemed completely unrelated - no doubt a bug,
>  but *not* a bug in pyxpcom, and hence no reason to not use pyxpcom from the
>  trunk.  Of course, its quite possible that other changes to the trunk have
>  broken pyxpcom on the trunk - in which case the only reasonable way forward
>  is to fix pyxpcom, as any such breakage would also exist for all versions in
>  the past.
> 
>  From your second email:
>  > On the topic of "pyxpcom isn't actively developed right now"
>  > is there a TODO list somewhere?
> 
>  Nope - there aren't really any desired features that have been identified.
>  If there are, they should be listed appropriately in bugzilla.  ActiveState
>  sometimes come up with new features (eg, Shane's recent work on exception
>  processing), but these are just dealt with as they identify them.
> 
>  > I'm new to the mozilla tree,
>  > but not to development in C or python, so this seems like a
>  > logical place for me to do my good deed for the day.
>  > Accessibility of python through the mozilla suite seems like
>  > such a cool idea, (especially with xulrunner and its kin)
>  > it's kind of startling to me that there aren't teams of
>  > seamonkeys working round the clock to make it happen.  I'd
>  > like to further that cause wherever I can, if there's cause
>  > to be furthered.
> 
>  By all means, feel free to do whatever tickles your fancy.  Upload any
>  patches you create to bugzilla and assign them to me.  Then join #pyxpcom
>  and/or email me to harrass me to look at the patches, and I'll either check
>  them in or explain in detail why I will not.  The more the merrier, and I
>  will do everything I can to encourage contributors.
> 
>  Cheers,
> 
>  Mark
> 
> 


-- 
"Time is an illusion.  Lunchtime, doubly so."

Ryan Sturmer
ryansturmer@[...].com
http://www.gogglemarks.net/
_______________________________________________
pyxpcom mailing list
pyxpcom@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs