constellation / crxmake Goto Github PK

Currently --pack-extension-key and --key-output are separated, but I suggest --pack-extension-key should be created if it doesn't exist.
See https://code.google.com/p/ctouch/source/browse/support/crx.rb

＃ Actually I lost some appid because of this...

In the example it's possible to generate a zip file for upload to the Google Chrome store however, it appears that the zip file is always deleted even when zip_output is specified.

C:/Ruby200-x64/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:53:in require ': cannot load such file -- zip (LoadError) from C:/Ruby200-x64/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:5 3:inrequire'
from D:/Users/grass/Desktop/extenstion/crxmake.rb:4:in `

I have this kind of directory structure:

manifest.json
background.html
...
plugin/... visual studio files
plugin/Release/... visual studio files
plugin/Release/np_myplugin.dll

I would like to include everything from root, and only plugin/Release/np_myplugin.dll but I cannot ignore the plugin or Release directories because np_myplugin.dll would be ignored, so it would be handy to have some kind of ignore-exclude switch to reversing some ignore parts.

On Windows 7:

> crxmake --pack-extension=path/with/utf8/sýmbøls --pack-extension-key=path/to/key --extension-output=path/to/output
extension dir not exist
option not valid

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec
via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

There is even a License Finder to help companies ensure all gems they use
meet their licensing needs. This tool depends on license information being available in the gemspec.
Including a license in your gemspec is a good practice, in any case.

How did I find you?

I'm using a script to collect stats on gems, originally looking for download data, but decided to collect licenses too,
and make issues for missing ones as a public service :)
https://gist.github.com/bf4/5952053#file-license_issue-rb-L13 So far it's going pretty well

If I have a tree like the following, I am unable to just ignore the private/data directory using --ignore-dir="private/data". I must use --ignore-dir="data", but if I do that my other data directories are removed.

   |-app
   |---cool
   |-----data
   |-data
   |-private
   |---data
   |---do-not-delete

The relevant code is on line 172 of lib/crxmake.rb: File.basename(path). Is there any reason not to just match against the full path? The same could be applied to files.

Obviously 100% up to you, but it seems like crxmake is no longer actively maintained -- perhaps it would be good to send users to my library instead? https://github.com/Zensight/extensionator

The gem install is failing for me, any clue what is going on?

$ gem source -a http://gemcutter.org
http://gemcutter.org added to sources

$ sudo gem install crxmake
Building native extensions. This could take a while...
ERROR: Error installing crxmake:
ERROR: Failed to build gem native extension.

/usr/bin/ruby1.8 extconf.rb
extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)
from extconf.rb:1

Gem files will remain installed in /var/lib/gems/1.8/gems/zipruby-0.3.6 for inspection.
Results logged to /var/lib/gems/1.8/gems/zipruby-0.3.6/ext/gem_make.out

$ gem --version
1.3.5

$ ruby --version
ruby 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]

I get an error "package is invalid: crx_signature_verification_initialization_failed" when trying to install a packaged app that has been generated using crxmake 2.2.0.

That must come from crxmake since manually packaging in Chrome (latest stable 31.0.1650.63, windows 8) with the same pem file does not raise the error.

The crx format must have changed, because the header looks like 4372 3234 0200 0000 3C01 0000 0001 0000 (hex), which according to the current doc (http://developer.chrome.com/extensions/crx.html) means a public key length of 15361 bytes, and a signature length of 1 byte, which does not make any sense.

I've also noticed that the pem file generated by chrome is now 1703 bytes long, when it used to be 916 bytes long. Could it be that crxmake does not handle the new pem file format?

in to_sizet you pack the value using "L", if it is correct for x86/amd64, shouldn't it be "V" used instead?