On Wed, Jan 16, 2013 at 06:21:47PM +0100, Cédric Boutillier wrote:
> > - There are quite a few ruby libraries that will need to be packaged for
> > Debian in order to get gitlab into our repos. I don't yet have an
> > exact number of new packages needed for 4.0.0, but it will probably be
> > well over a dozen packages. Will that be a problem? If not, how would
> > we manage so many sponsorship requests?
>
> I think it is not a problem. Could you please get a precise list of
> these missing packages? You should then send ITP/RFP bugs for each of
> these. Maybe someone will help and package some of them.
After having a look at the ruby bundler docs, I still didn't know how to
get a precise list for it. Alexander suggested the following:
% grep '^GEM' -A1000 Gemfile.lock |grep '^ [^ ]'
Whose ouput is as follows:
actionmailer (3.2.9)
actionpack (3.2.9)
activemodel (3.2.9)
activerecord (3.2.9)
activeresource (3.2.9)
activesupport (3.2.9)
acts-as-taggable-on (2.3.3)
addressable (2.3.2)
arel (3.0.2)
awesome_print (1.1.0)
backports (2.6.5)
bcrypt-ruby (3.0.1)
blankslate (3.1.2)
bootstrap-sass (2.2.1.1)
builder (3.0.4)
capybara (1.1.3)
carrierwave (0.7.1)
charlock_holmes (0.6.9)
childprocess (0.3.6)
chosen-rails (0.9.8)
coderay (1.0.8)
coffee-rails (3.2.2)
coffee-script (2.2.0)
coffee-script-source (1.4.0)
colored (1.2)
colorize (0.5.8)
crack (0.3.1)
daemons (1.1.9)
devise (2.1.2)
diff-lcs (1.1.3)
draper (0.18.0)
email_spec (1.4.0)
erubis (2.7.0)
escape_utils (0.2.4)
eventmachine (1.0.0)
execjs (1.4.0)
factory_girl (4.1.0)
factory_girl_rails (4.1.0)
faraday (0.8.4)
faye-websocket (0.4.6)
ffaker (1.15.0)
ffi (1.1.5)
font-awesome-sass-rails (2.0.0.0)
foreman (0.60.2)
gemoji (1.2.1)
gherkin-ruby (0.2.1)
git (1.2.5)
github-linguist (2.3.4)
github-markup (0.7.4)
gitlab_meta (4.0)
gitolite (1.1.0)
grape (0.2.2)
gratr19 (0.4.4.1)
growl (1.0.3)
guard (1.5.4)
guard-rspec (2.1.2)
guard-spinach (0.0.2)
haml (3.1.7)
haml-rails (0.3.5)
hashery (1.5.0)
hashie (1.2.0)
hike (1.2.1)
http_parser.rb (0.5.3)
httparty (0.9.0)
httpauth (0.2.0)
i18n (0.6.1)
journey (1.0.4)
jquery-atwho-rails (0.1.7)
jquery-rails (2.1.3)
jquery-ui-rails (2.0.2)
json (1.7.5)
jwt (0.1.5)
kaminari (0.14.1)
kgio (2.7.4)
launchy (2.1.2)
letter_opener (1.0.0)
libv8 (3.3.10.4)
libwebsocket (0.1.6)
listen (0.5.3)
lumberjack (1.0.2)
mail (2.4.4)
method_source (0.8.1)
mime-types (1.19)
modernizr (2.6.2)
multi_json (1.3.7)
multi_xml (0.5.1)
multipart-post (1.1.5)
mysql2 (0.3.11)
net-ldap (0.2.2)
nokogiri (1.5.5)
oauth (0.4.7)
oauth2 (0.8.0)
omniauth (1.1.1)
omniauth-github (1.0.3)
omniauth-google-oauth2 (0.1.13)
omniauth-oauth (1.0.1)
omniauth-oauth2 (1.1.1)
omniauth-twitter (0.0.14)
orm_adapter (0.4.0)
pg (0.14.1)
polyglot (0.3.3)
posix-spawn (0.3.6)
pry (0.9.10)
pyu-ruby-sasl (0.0.3.3)
quiet_assets (1.0.1)
rack (1.4.1)
rack-accept (0.4.5)
rack-cache (1.2)
rack-mini-profiler (0.1.23)
rack-mount (0.8.3)
rack-protection (1.2.0)
rack-ssl (1.3.2)
rack-test (0.6.2)
rails (3.2.9)
rails-dev-tweaks (0.6.1)
railties (3.2.9)
raindrops (0.10.0)
rake (10.0.1)
raphael-rails (1.5.2)
rb-fsevent (0.9.2)
rb-inotify (0.8.8)
rdoc (3.12)
redcarpet (2.2.2)
redis (3.0.2)
redis-namespace (1.2.1)
resque (1.23.0)
resque_mailer (2.1.0)
resque_spec (0.12.5)
rspec (2.12.0)
rspec-core (2.12.0)
rspec-expectations (2.12.0)
rspec-mocks (2.12.0)
rspec-rails (2.12.0)
rubyntlm (0.1.1)
rubyzip (0.9.9)
sass (3.2.3)
sass-rails (3.2.5)
seed-fu (2.2.0)
selenium-webdriver (2.26.0)
settingslogic (2.0.8)
shoulda-matchers (1.3.0)
simplecov (0.7.1)
simplecov-html (0.7.1)
sinatra (1.3.3)
six (0.2.0)
slop (3.3.3)
spinach (0.5.2)
spinach-rails (0.1.8)
sprockets (2.2.1)
stamp (0.3.0)
test_after_commit (0.0.1)
therubyracer (0.10.2)
thin (1.5.0)
thor (0.16.0)
tilt (1.3.3)
treetop (1.4.12)
tzinfo (0.3.35)
uglifier (1.3.0)
unicorn (4.4.0)
vegas (0.1.11)
virtus (0.5.2)
warden (1.2.1)
webmock (1.9.0)
websocket (1.0.2)
xpath (0.1.4)
yajl-ruby (1.1.0)
Of course, we must add bundler to the list. Do you know of any better
method to find all deps, including the non-direct ones?
> There is currently an effort to package diaspora, and they have the same
> problem. There has always been someone to review the packages and upload
> once ready, so this should be ok. Just send RFS email to the debian-ruby
> list.
Ah, so there's no need to bother debian-mentors and
sponsorship-requests? Or do I just post a regular RFS with debian-ruby
as Cc?
> > - In gitlab's Gemfile, I can see where it needs some specific patched
> > libs in order to function. Thus, they would be of no use to any other
> > programs, which is why I don't know how to package them. Perhaps as
> > gitlab-libs? This is the bit that troubles me:
>
> > # GITLAB patched libs
> > gem "grit", git: "https://github.com/gitlabhq/grit.git";, ref: '7f35cb98ff17d534a07e3ce6ec3d580f67402837'
> > gem "omniauth-ldap", git: "https://github.com/gitlabhq/omniauth-ldap.git";, ref: 'f038dd852d7bd473a557e385d5d7c2fd5dc1dc2e'
> > gem 'yaml_db', git: "https://github.com/gitlabhq/yaml_db.git";, ref: '98e9a5dca43e3fedd3268c76a73af40d1bdf1dfd'
> > gem 'grack', git: "https://github.com/gitlabhq/grack.git";, ref: 'ba46f3b0845c6a09d488ae6abdce6ede37e227e8'
> > gem 'grit_ext', git: "https://github.com/gitlabhq/grit_ext.git";, ref: '8e6afc2da821354774aa4d1ee8a1aa2082f84a3e'
>
> > Most of the dependencies just require a minimum or specific version,
> > or even no specific version at all. These won't be a problem. But
> > gitlab's patched dependencies are not only specific to the package,
> > but are bound specific to a git ref as well.
>
> If they diverged too much, then you may need to package them separately
> indeed. Some of these patched libraries have departed very little from
> upstream (I just looked at yaml_db), so it might be possible to use the
> original ones?
Even if they diverged very lightly with the original ones, I believe it
will be easier to package them separately. Since they are specific to
gitlab, I suggest we package them under a gitlab-* name. Any
suggestions?
> We usually try to run the tests during the package creation. You may
> want to do the same, and thus may need the gems in the :test bloc as
> Build-Dependencies.
OK, we'll add them.
> I am sure it will!
Perfect!
Thank you for your time again.
--
Daniel Martí - mvdan@mvdan.cc - GPG 0x58BF72C3
Attachment:
pgpAIO35GVEcB.pgp
Description: PGP signature