Regarding gitlab

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Regarding gitlab

Daniel Martí-2
Hello everyone,

> I would be happy to help with that and review and/or upload packages for
> Ruby gems needed for gitlab. Just contact [hidden email]
> for questions or your RFS requests.
>
> Cheers,
>
> Cédric

I couldn't do much about gitlab during the break, but I'm now making up
for it :) I contacted Alexander Golovko <[hidden email]>, who
has forked the gitlab project from github and worked on a working debian
package. He has allowed me to work on gitlab taking advantage on his
already done work, which is fantastic. There will need to be lots of
modifications, like the removing of the binary gitlab-bundle package for
the ruby gems amongst others.

Just a few questions:

- I believe it is sensible to keep his current changelog file in
  essence, since it has been him doing the work on the package source.
  Would you agree? Would it be better to sum it all up in one pre-debian
  changelog entry, or would it be best to just ignore his changelog and
  just mention him in the debian/copyright file?

- I'll need to package a few gems, as well as gitlab itself. The plan is
  to package them all under pkg-ruby-extras; would that suit you? I see
  here [0] that many other apps such as jekyll are in there too, so I
  guess it fits in there.

- Will we wait for the freeze to end to start bringing the packages to
  the main repos, or will we start using sid/experimental right away?
  I'm not very experienced with ITPs as of yet, I was just wondering.

Thank you for your time.

Dan

[0] http://qa.debian.org/developer.php?login=pkg-ruby-extras-maintainers@...

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Cédric Boutillier-6
Hi Daniel,

[Cc:ing you because I'm not sure you are subscribed to debian-ruby]

On Wed, Jan 09, 2013 at 10:19:07AM +0100, Daniel Martí wrote:

> I couldn't do much about gitlab during the break, but I'm now making up
> for it :) I contacted Alexander Golovko <[hidden email]>, who
> has forked the gitlab project from github and worked on a working debian
> package. He has allowed me to work on gitlab taking advantage on his
> already done work, which is fantastic. There will need to be lots of
> modifications, like the removing of the binary gitlab-bundle package for
> the ruby gems amongst others.

> Just a few questions:

> - I believe it is sensible to keep his current changelog file in
>   essence, since it has been him doing the work on the package source.
>   Would you agree? Would it be better to sum it all up in one pre-debian
>   changelog entry, or would it be best to just ignore his changelog and
>   just mention him in the debian/copyright file?

I think it will be a bit confusing if you keep the current changelog
entries in debian/changelog, as they are documented as being uploaded to
unstable, but in fact there were not. So I would remove these entries,
but you can add in your changelog entry a paragraph about the changes
made by Alexander Golovko (in a summarized form)

  [ Alexander Golovko ]
  * this

  [ You ]
  * this

But maybe others have another opinion on this.

> - I'll need to package a few gems, as well as gitlab itself. The plan is
>   to package them all under pkg-ruby-extras; would that suit you? I see
>   here [0] that many other apps such as jekyll are in there too, so I
>   guess it fits in there.

Yes, it fits. Ask to join pkg-ruby-teams if you haven't done it already.

> - Will we wait for the freeze to end to start bringing the packages to
>   the main repos, or will we start using sid/experimental right away?
>   I'm not very experienced with ITPs as of yet, I was just wondering.

You can start with sid right away for new packages. If you need to
update some packages already present in the archive to a newer version,
then you should target experimental. In any case, there is no need to
wait the end of the freeze (although during the freeze, it can take a
long time to have new packages enter the archive).


Cheers,

Cédric

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Paul Tagliamonte-3
In reply to this post by Daniel Martí-2
Please keep me on CC, I'm not on the list


On Wed, Jan 09, 2013 at 10:19:07AM +0100, Daniel Martí wrote:

> Hello everyone,
>
> > I would be happy to help with that and review and/or upload packages for
> > Ruby gems needed for gitlab. Just contact [hidden email]
> > for questions or your RFS requests.
> >
> > Cheers,
> >
> > Cédric
>
> I couldn't do much about gitlab during the break, but I'm now making up
> for it :) I contacted Alexander Golovko <[hidden email]>, who
> has forked the gitlab project from github and worked on a working debian
> package. He has allowed me to work on gitlab taking advantage on his
> already done work, which is fantastic. There will need to be lots of
> modifications, like the removing of the binary gitlab-bundle package for
> the ruby gems amongst others.
>
> Just a few questions:
>
> - I believe it is sensible to keep his current changelog file in
>   essence, since it has been him doing the work on the package source.
>   Would you agree? Would it be better to sum it all up in one pre-debian
>   changelog entry, or would it be best to just ignore his changelog and
>   just mention him in the debian/copyright file?

I would ask that it only contain a single entry, with a single changelog
item, closing the ITP. You can thank him in the debian/copyright, or if
he'd like to be a co-maintainer.

>
> - I'll need to package a few gems, as well as gitlab itself. The plan is
>   to package them all under pkg-ruby-extras; would that suit you? I see
>   here [0] that many other apps such as jekyll are in there too, so I
>   guess it fits in there.

I'll let the rubyists answer that :)

>
> - Will we wait for the freeze to end to start bringing the packages to
>   the main repos, or will we start using sid/experimental right away?
>   I'm not very experienced with ITPs as of yet, I was just wondering.

It's quite alright to push to unstable, if the package is already NEW,
since it won't be in testing anyway, so updates to testing via unstable
aren't needed

>
> Thank you for your time.

Quite! Thank you for yours!

>
> Dan
>
> [0] http://qa.debian.org/developer.php?login=pkg-ruby-extras-maintainers@...
>
> --
> Daniel Martí - [hidden email] - GPG 0x58BF72C3

Cheers,
  Paul

--
 .''`.  Paul Tagliamonte <[hidden email]>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
In reply to this post by Cédric Boutillier-6
> On Wed, Jan 09, 2013 at 06:16:33PM +0100, Cédric Boutillier wrote:
> > Hi Daniel,
> >
> > [Cc:ing you because I'm not sure you are subscribed to debian-ruby]

On Wed, Jan 09, 2013 at 01:38:06PM -0500, Paul Tagliamonte wrote:
> Please keep me on CC, I'm not on the list

It is him we should CC, not me :) I quoted Cédric's replies so that Paul
can catch up.

> > I think it will be a bit confusing if you keep the current changelog
> > entries in debian/changelog, as they are documented as being uploaded to
> > unstable, but in fact there were not. So I would remove these entries,
> > but you can add in your changelog entry a paragraph about the changes
> > made by Alexander Golovko (in a summarized form)
> >
> >   [ Alexander Golovko ]
> >   * this
> >
> >   [ You ]
> >   * this
> >
> > But maybe others have another opinion on this.

> I would ask that it only contain a single entry, with a single changelog
> item, closing the ITP. You can thank him in the debian/copyright, or if
> he'd like to be a co-maintainer.

OK, I'll follow Cedric's advice on this matter. I will also mention him
in debian/copyright, since AFAIK that's mandatory. I hadn't thought
about asking him whether he wants to co-maintain; that's a great idea!

> > Yes, it fits. Ask to join pkg-ruby-teams if you haven't done it already.

> I'll let the rubyists answer that :)

I joined pkg-ruby-teams on alioth as mvdan-guest. Hopefully that will be
enough.

> > You can start with sid right away for new packages. If you need to
> > update some packages already present in the archive to a newer version,
> > then you should target experimental. In any case, there is no need to
> > wait the end of the freeze (although during the freeze, it can take a
> > long time to have new packages enter the archive).

> It's quite alright to push to unstable, if the package is already NEW,
> since it won't be in testing anyway, so updates to testing via unstable
> aren't needed

Brilliant. I'll be submitting the ITPs as things get moving.

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
In reply to this post by Paul Tagliamonte-3
On Wed, Jan 09, 2013 at 01:38:06PM -0500, Paul Tagliamonte wrote:
> I would ask that it only contain a single entry, with a single changelog
> item, closing the ITP. You can thank him in the debian/copyright, or if
> he'd like to be a co-maintainer.

As a side note, he agreed to co-maintain. He'll request membership for
the pkg-ruby-extras team at alioth, so please let him in.

Regards.

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Antonio Terceiro-3
On Thu, Jan 10, 2013 at 11:46:51AM +0100, Daniel Martí wrote:
> On Wed, Jan 09, 2013 at 01:38:06PM -0500, Paul Tagliamonte wrote:
> > I would ask that it only contain a single entry, with a single changelog
> > item, closing the ITP. You can thank him in the debian/copyright, or if
> > he'd like to be a co-maintainer.
>
> As a side note, he agreed to co-maintain. He'll request membership for
> the pkg-ruby-extras team at alioth, so please let him in.

I've just approved him.

Thanks for working on this, it will be awesome to have gitlab on Debian.
Specially when the feature of allowing public repos is implemented, this
will be a properly packaged free alternative to Github that sucks less
than the others.

--
Antonio Terceiro <[hidden email]>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
Hello everyone,

Alexander is working on updating his gitlab/gitlab-bundle debian package
to the latest stable release, 4.0.0. Once he's done, I'll be able to
adapt it to the Debian standards.

I just have a few questions once again :)

- 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?

- 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.

- Under the same Gemfile, there are a few dependency groups; :assets,
  :development, :test and :production. My first impression is to package
  just the former and the last, since devel and test seem like they
  won't be needed for normal use. Would that be correct?

- Even if we packaged all the missing dependencies, as of now packages
  like rails3 do not meet the minimum version required by gitlab. I
  suppose rails3 has been kept frozen since August, so surely it will be
  updated once Wheezy is released, right?

Thank you all for your time and patience!

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Cédric Boutillier

Hi Daniel,


On Wed, Jan 16, 2013 at 10:26:56AM +0100, Daniel Martí wrote:
> Hello everyone,

> Alexander is working on updating his gitlab/gitlab-bundle debian package
> to the latest stable release, 4.0.0. Once he's done, I'll be able to
> adapt it to the Debian standards.

Great news!

> I just have a few questions once again :)

> - 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.

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.

> - 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?

> - Under the same Gemfile, there are a few dependency groups; :assets,
>   :development, :test and :production. My first impression is to package
>   just the former and the last, since devel and test seem like they
>   won't be needed for normal use. Would that be correct?

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.

> - Even if we packaged all the missing dependencies, as of now packages
>   like rails3 do not meet the minimum version required by gitlab. I
>   suppose rails3 has been kept frozen since August, so surely it will be
>   updated once Wheezy is released, right?

I am sure it will!

Cheers,

Cédric


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
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í - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Antonio Terceiro-3
On Sun, Jan 20, 2013 at 01:34:51PM +0100, Daniel Martí wrote:

> 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:
>
[snip long list of gems]
>
> Of course, we must add bundler to the list.

No we don't. ruby-rails-3.2 already depends on bundler.

> Do you know of any better method to find all deps, including the
> non-direct ones?

You should be good by looking at the Gemfile itself.

You don't need to include transitive dependencies. Just stick to the
direct dependencies and assume that they have their dependencies sorted
out.

> > 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?

Yep.

> > > - 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?
IMO this is very wrong. The best way to go forward would be to push
those changes to the original upstream packages and have them packaged.
Are the changes really specific to gitlab?

Besides, if you package those modified versions they would have to
conflict with packages of the original packages, which might create
weird situations where $foo and gitlab cannot be co-installed.

The best (and maybe only) way to achieve sane packaging is having a sane
upstream.

--
Antonio Terceiro <[hidden email]>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
On Sun, Jan 20, 2013 at 11:06:25AM -0300, Antonio Terceiro wrote:
> No we don't. ruby-rails-3.2 already depends on bundler.

Fair enough.

> You should be good by looking at the Gemfile itself.
>
> You don't need to include transitive dependencies. Just stick to the
> direct dependencies and assume that they have their dependencies sorted
> out.

I suppose we would take care of the second-level dependencies when
packaging the direct ones. Is that right?

> > 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?
>
> Yep.

Sorry, which question are you replying to? The latter, about CCing
debian-ruby on a regular RFS?

> > 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?
>
> IMO this is very wrong. The best way to go forward would be to push
> those changes to the original upstream packages and have them packaged.
> Are the changes really specific to gitlab?
>
> Besides, if you package those modified versions they would have to
> conflict with packages of the original packages, which might create
> weird situations where $foo and gitlab cannot be co-installed.
>
> The best (and maybe only) way to achieve sane packaging is having a sane
> upstream.
I will contact upstream and ask for his current and future approach.

My original idea was to create a gitlab-bundle package, containing the
modified libraries which would be installed separately from the rest.
Then, gitlab would use these modified ones instead of the original ones.
This way, there'd be no conflicts. But it would be very messy, and an
extra load of work for us.

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Per Andersson-3
Hi!

I would very much like to see gitlab in Debian.

If you need help, sponsorship or want to co-maintain I would be happy to
help out!


>> You should be good by looking at the Gemfile itself.
>>
>> You don't need to include transitive dependencies. Just stick to the
>> direct dependencies and assume that they have their dependencies sorted
>> out.
>
> I suppose we would take care of the second-level dependencies when
> packaging the direct ones. Is that right?

Yes, if they aren't already packaged.


>> > 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?
>>
>> Yep.
>
> Sorry, which question are you replying to? The latter, about CCing
> debian-ruby on a regular RFS?

You can submit a regular RFS and Cc debian-ruby.


>> > 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?
>>
>> IMO this is very wrong. The best way to go forward would be to push
>> those changes to the original upstream packages and have them packaged.
>> Are the changes really specific to gitlab?
>>
>> Besides, if you package those modified versions they would have to
>> conflict with packages of the original packages, which might create
>> weird situations where $foo and gitlab cannot be co-installed.
>>
>> The best (and maybe only) way to achieve sane packaging is having a sane
>> upstream.
I agree fully with this.


> I will contact upstream and ask for his current and future approach.
>
> My original idea was to create a gitlab-bundle package, containing the
> modified libraries which would be installed separately from the rest.
> Then, gitlab would use these modified ones instead of the original ones.
> This way, there'd be no conflicts. But it would be very messy, and an
> extra load of work for us.

As Antonio said, the changes should go upstream.

If they cannot I suggest to patch the already existing Debian package
(or clean upstream to be packaged) so it supports whatever the fork
supports (if it is sane).

If things get complicated, discuss here. :-)


I checked the Gemfile and made a very naive script to check if the
required packages are packaged or not.

The quick glance reports about 66 packages, heads up for false positives
and negatives!

Depending on if the developement group can be ommitted, it is eight
packages less to package. (The development group is nine packages but
I suggest sdoc is good to have in order to generate docs.) I am sorry to
say that I am not too sure about Gemfiles but I suppose that the
development, test group can be ommitted as well, that is another fifteen
packages less.

That would total in about 40 primary dependencies not yet packaged.


I have attached the script and it's output. Maybe someone more
knowledgable in Ruby and Gemfile land can take a peek at it?


--
Per

gitlab-debian-missing-deps.sh (718 bytes) Download Attachment
gitlab.deb-deps (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
On Sun, Jan 20, 2013 at 10:59:02PM +0100, Per Andersson wrote:
> Hi!
>
> I would very much like to see gitlab in Debian.
>
> If you need help, sponsorship or want to co-maintain I would be happy to
> help out!

You have all been very supportive, thank you again :)

> You can submit a regular RFS and Cc debian-ruby.

Perfect, thank you.

> As Antonio said, the changes should go upstream.
>
> If they cannot I suggest to patch the already existing Debian package
> (or clean upstream to be packaged) so it supports whatever the fork
> supports (if it is sane).
>
> If things get complicated, discuss here. :-)

Fair enough.

> I checked the Gemfile and made a very naive script to check if the
> required packages are packaged or not.
>
> The quick glance reports about 66 packages, heads up for false positives
> and negatives!
>
> Depending on if the developement group can be ommitted, it is eight
> packages less to package. (The development group is nine packages but
> I suggest sdoc is good to have in order to generate docs.) I am sorry to
> say that I am not too sure about Gemfiles but I suppose that the
> development, test group can be ommitted as well, that is another fifteen
> packages less.
>
> That would total in about 40 primary dependencies not yet packaged.
>
> I have attached the script and it's output. Maybe someone more
> knowledgable in Ruby and Gemfile land can take a peek at it?
Thank you, it seems to run just fine!

I believe we should only avoid :development, since the rest of the
dependency groups will be needed. Hopefully most of these deps will be
useful for other packages in the future.

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Cédric Boutillier
Hi,

On Sun, Jan 20, 2013 at 11:26:44PM +0100, Daniel Martí wrote:
> On Sun, Jan 20, 2013 at 10:59:02PM +0100, Per Andersson wrote:

> > I have attached the script and it's output. Maybe someone more
> > knowledgable in Ruby and Gemfile land can take a peek at it?

> Thank you, it seems to run just fine!

To complete the picture, I add a link to a graph [0] showing
dependencies scrapped from rubygems.org, using a poor homemade
script [1] I wrote for diaspora, and quickly adapted to gitlab.
I started from _all_ gems listed in the Gemfile, though.

  0: http://people.debian.org/~boutil/gitlab/gitlab_deps20130120.pdf
  1: https://gitorious.org/debian-diaspora/gemdeps

green is in Debian
yellow is waiting in NEW
orange is ITP
purple is RFP


Best,

Cédric


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Antonio Terceiro-3
On Mon, Jan 21, 2013 at 12:35:31AM +0100, Cédric Boutillier wrote:

> Hi,
>
> On Sun, Jan 20, 2013 at 11:26:44PM +0100, Daniel Martí wrote:
> > On Sun, Jan 20, 2013 at 10:59:02PM +0100, Per Andersson wrote:
>
> > > I have attached the script and it's output. Maybe someone more
> > > knowledgable in Ruby and Gemfile land can take a peek at it?
>
> > Thank you, it seems to run just fine!
>
> To complete the picture, I add a link to a graph [0] showing
> dependencies scrapped from rubygems.org, using a poor homemade
> script [1] I wrote for diaspora, and quickly adapted to gitlab.
> I started from _all_ gems listed in the Gemfile, though.
>
>   0: http://people.debian.org/~boutil/gitlab/gitlab_deps20130120.pdf
>   1: https://gitorious.org/debian-diaspora/gemdeps
>
> green is in Debian
> yellow is waiting in NEW
> orange is ITP
> purple is RFP
That seems intimidating! :-/

I tried to mark which dependencies in the Gemfile should not be
strictly required (mainly development tools) to try achieving a more
tractable dependency graph.

I tried to re-generate the graph myself but failed miserably. Cédric,
could you give a hand with this?

Attached you will find an annotated version of gitlab Gemfile, where the
lines marked with @debian indicate dependencies that should not be
needed for a Debian package (Gemfile.debian); and a "clean" Gemfile
resulting from `grep -v debian Gemfile.debian` (Gemfile), that could be
a base for a reduced dependency graph.

--
Antonio Terceiro <[hidden email]>

Gemfile.debian (4K) Download Attachment
Gemfile (3K) Download Attachment
signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Cédric Boutillier
Hi,

On Wed, Jan 23, 2013 at 11:40:40AM -0300, Antonio Terceiro wrote:

> That seems intimidating! :-/

> I tried to mark which dependencies in the Gemfile should not be
> strictly required (mainly development tools) to try achieving a more
> tractable dependency graph.

> I tried to re-generate the graph myself but failed miserably. Cédric,
> could you give a hand with this?

> Attached you will find an annotated version of gitlab Gemfile, where the
> lines marked with @debian indicate dependencies that should not be
> needed for a Debian package (Gemfile.debian); and a "clean" Gemfile
> resulting from `grep -v debian Gemfile.debian` (Gemfile), that could be
> a base for a reduced dependency graph.

Thanks Antonio for this cleaned Gemfile.
I extracted from it the names of the gems, and generated a new graph

  http://people.debian.org/~boutil/gitlab/gitlab_deps20130123.pdf

which looks (a bit) less intimidating than the previous one.

The legend is still the same:
> > green is in Debian
> > yellow is waiting in NEW
> > orange is ITP
> > purple is RFP

Again, this script is very naive, and does not do any version check, and
uses only dependency information provided by the gems and advertised on
rubygems.org, but at least, it is a starting point.

I should try to do the same sort of cleaning for diaspora, since I
blindly took all the entries of the gemfile...

Cheers,

Cédric

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Per Andersson-3
Hi!

On Wed, Jan 23, 2013 at 11:22 PM, Cédric Boutillier
<[hidden email]> wrote:
>
> Thanks Antonio for this cleaned Gemfile.
> I extracted from it the names of the gems, and generated a new graph
>
>   http://people.debian.org/~boutil/gitlab/gitlab_deps20130123.pdf

Neat, great work!

The gem rubyntlm is a false positive, it is already packaged as ruby-ntlm.


> which looks (a bit) less intimidating than the previous one.

Indeed. :-)

What are typical developer gems that are not a requirement for running
tests?

So far Antonio has flagged pry and guard. Any other common gems that
can


--
Per


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CABYrXSQRh_=_=yr3H1mtygyxSd8+B57R3OwNpiSp9Pv_NRJryA@...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Antonio Terceiro-3
On Thu, Jan 24, 2013 at 09:48:47AM +0100, Per Andersson wrote:

> Hi!
>
> On Wed, Jan 23, 2013 at 11:22 PM, Cédric Boutillier
> <[hidden email]> wrote:
> >
> > Thanks Antonio for this cleaned Gemfile.
> > I extracted from it the names of the gems, and generated a new graph
> >
> >   http://people.debian.org/~boutil/gitlab/gitlab_deps20130123.pdf
>
> Neat, great work!
>
> The gem rubyntlm is a false positive, it is already packaged as ruby-ntlm.
>
>
> > which looks (a bit) less intimidating than the previous one.
>
> Indeed. :-)
>
> What are typical developer gems that are not a requirement for running
> tests?
>
> So far Antonio has flagged pry and guard. Any other common gems that
> can
Another common one is spork, plus the ones I flagged at gitlab's Gemfile
(note however that I might be wrong for some of them).

Usually you should double check everything listed inside :development
and :test groups, and ask yourself whether that makes sense while
running the tests in a package build.

--
Antonio Terceiro <[hidden email]>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
Hello Antonio, Per and company,

My apologies for not getting back to you earlier. The graph will be of
great help, thank you!

I emailed upstream twice about the custom ruby dependencies, but got no
reply so far. Will try a third time and report back.

In the meantime, I'll start working in the dependencies.

Regards.

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Regarding gitlab

Daniel Martí-2
On Sun, Mar 03, 2013 at 20:33:09 +0100, Daniel Martí wrote:
> I emailed upstream twice about the custom ruby dependencies, but got no
> reply so far. Will try a third time and report back.

He did reply this time. And I quote:

> We use patched libraries because we need some fixes and improvements over
> native one.

I asked whether he tried merging those changes into their respective
upstream repositories.

> I can build a gems like `gitlab-grit` or something if it saves you a lot of
> efforts.

Would this be a valid workaround? AFAIK the gems would not conflict with
the original ones. It wouldn't be the cleanest of the solutions, but it
might just work (if the "merge the changes into the gems" option is not
possible).

Any opinions?

--
Daniel Martí - [hidden email] - GPG 0x58BF72C3

attachment0 (853 bytes) Download Attachment
123