[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: firefox-greasemonkey

Don Armstrong wrote:

>On Mon, 13 Mar 2006, Michael Spang wrote:
> That's fine, you can make that the orig.tar.gz

Easier said than done ;-). The guest account apparently doesn't
have permission to check out or update to the 0.6.4 tag. I don't
think using the current HEAD is a good idea, either, since it
doesn't appear to be in a releasable state.

$ cvs status -v install.rdf
File: install.rdf       Status: Up-to-date


   Existing Tags:
        v0_6_4                          (revision:

$ cvs update -r v0_6_4
cvs update: User 'guest' cannot access
cvs update: User 'guest' cannot access chrome
cvs update: User 'guest' cannot access chromeFiles
cvs update: User 'guest' cannot access components
cvs update: User 'guest' cannot access content
cvs update: User 'guest' cannot access idl
cvs update: User 'guest' cannot access locale
cvs update: User 'guest' cannot access perl
cvs [update aborted]: no such tag v0_6_4

>1) You can't easily patch any of the files in the xpi
>2) You're not directly distributing the source
The indirection caused by the XPI is indeed problematic
in some cases. Perhaps I should just extract it? The layout
of the CVS tree is identical to the one in the XPI. The repository
just has numerous empty directories. I could grab the .idl files
from the CVSWEB interface and add those so that everything is present.

>3) Upstream's build process is totally different from yours.
Well, the difference in the processes is due to a difference in
requirements. They need
only to zip everything up into an XPI, letting each Firefox handle
installation. A debian
package needs to handle the installation the extension's components to
Firefox's extension
tree since Firefox obviously cannot be used to do so. Also, I haven't
seen any evidence of
build infrastructure, so this will always be the case until that changes
(really, there are
no build scripts whatsoever in cvs). Perhaps they do everything
manually? Not that there's
much to build, since everything is in JavaScript.

>4) Security fixes are very, very difficult to do because of #1-3.
Point taken. I will see what I can do, but my options are quite limited
at the moment without help from upstream. I'll send an email to the
mailing lists to see if anything can be done.

Michael Spang

Reply to: