Ruby 2.0
by Vít Ondruch
Hi,
Just for your information, I have pushed ruby-2.0 branch into the Ruby's
git repo. So if you like test the latest Ruby, you need to get the
latest HEAD tarball, which could be prepared using:
$ cd /path/to/your/ruby/sources
$ ./tool/make-snapshot tmp
Note that you have to have available subversion and bison on your
system. Also note that the content of tarball is needed to be repacked,
that the Ruby sources will be stored in "ruby-2.0.0-p0" folder (I know,
it is annoyance, but you can fix the spec and send me a patch ;). Also
note that I currently keep the ruby_abi at 1.9.1, while the official
release will have 2.0.0 probably. This should allow you to use Fedora's
gems without rebuild. Any comments/patches are appreciated.
Vit
[1]
http://pkgs.fedoraproject.org/gitweb/?p=ruby.git;a=tree;h=refs/heads/ruby...
10 years, 6 months
ruby-dbus status
by "Guillermo Gómez S."
Im working on a little ruby dbus project and i noticed our version is
kind of old now.
f16 repoquery info
Name : ruby-dbus
Version : 0.3.0
Release : 2.fc15
URL : http://trac.luon.net/ruby-dbus/
According that site the last version available is 0.7.0 and its
available as a gem from rubygems.org, can i help and comaintain?
(unleast i can try) Any reason to keep the actual version?
cheers
_- Guillermo -_
11 years, 2 months
Re: [Fedora-packaging] New packaging guidelines for Ruby
by Vít Ondruch
Dne 29.2.2012 15:23, Stanislav Ochotnicky napsal(a):
> Quoting Emanuel Rietveld (2012-02-29 12:18:57)
>> On 02/29/2012 11:50 AM, Nicolas Mailhot wrote:
>>> Le Mar 28 février 2012 16:29, Vít Ondruch a écrit :
>>>
>>>> Pleas do not be mistaken. We are not speaking about building gems from
>>>> sources. We are speaking about building from package manager output,
>>>> i.e. build gem from gem.
>>> So we are shipping stuff, which is not build from other stuff we ship, but
>>> from magic upstream binaries? Not nice at all.
>>>
>> It is worth noting that .java files compiled into .class files or .jar
>> files is not the same thing as .rb files. .rb files are not compiled*
> However I have seen gem files containing bundled jar files. Not sure if
> gem unpacking actually helps things, but it might make it more easy to
> spot perhaps. There as easy ways to detect such bundling though, so not
> a problem. Just though I'd mention this use case
>
Yes, there are gems with bundled jar files. There are also gems which
might carry other binaries. For this case, there apply general Fedora's
"No inclusion of pre-built binaries or libraries" and "Duplication of
system libraries" policies, nothing specific is needed for Ruby.
Please note that we proposed to do "gem install" in %prep section which
"unpacks" the gem content among other things, so you can spot such files
easily.
Vit
11 years, 3 months
Re: [Fedora-packaging] New packaging guidelines for Ruby
by Vít Ondruch
Dne 28.2.2012 17:43, Rex Dieter napsal(a):
> On 02/28/2012 10:36 AM, Vít Ondruch wrote:
>> May be you could elaborate a bit what do you want to achieve and what is
>> the reasoning. What do you mean by "not building from (preferred form)
>> source" anyway?
>
> So, perhaps I'm showing some ignorance here. Do these guidelines
> allow for packaging pre-built gems (similar to pre-built java .jar
> files) or are they genuinely being built completely from source?
>
> Maybe I'm confusing that with gems being built and generated in one
> step, rather than the rpm notion of extracting source/patching
> (%prep), building stuff (%build), and installing into buildroot
> (%install).
>
> -- rex
> --
> packaging mailing list
> packaging(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging
Ok, I'll give you 3 examples:
= Old guidelines, used from the time RubyGems were packaged for Fedora =
%prep
%build
%install
mkdir -p %{buildroot}%{gem_dir}
gem install --local --install-dir %{buildroot}%{gem_dir} \
--force %{SOURCE0}
= What we are proposing =
%prep
%setup -q -c -T
mkdir -p .%{gem_dir}
gem install --local --install-dir .%{gem_dir} \
--force %{SOURCE0}
%build
%install
mkdir -p %{buildroot}%{gem_dir}
cp -a .%{gem_dir}/* \
%{buildroot}%{gem_dir}/
= What FPC is proposing =
%prep
%setup -q -c -T
pushd ..
gem unpack %{SOURCE0}
pushd %{gem_name}-%{version}
gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec
gem build %{gem_name}.gemspec
popd
popd
%build
mkdir -p ./%{gem_dir}
gem install --local --install-dir ./%{gem_dir} \
--force ../%{gem_name}-%{version}/%{gem_name}-%{version}.gem
%install
mkdir -p %{buildroot}%{gem_dir}
cp -a .%{gem_dir}/* \
%{buildroot}%{gem_dir}/
All three versions provide the same output, unless I did some mistake,
since I did not tested it (actually the middle one was taken directly
from rubygem-POpen4.spec). So which version you prefer? Please note that
the "gem install" will always "unpack" the gem with some additional, for
our case unimportant, steps. We do not distribute the .gem file anywhere.
Vit
11 years, 3 months
Re: [Fedora-packaging] New packaging guidelines for Ruby
by Vít Ondruch
Dne 28.2.2012 18:05, Rex Dieter napsal(a):
> On 02/28/2012 10:56 AM, Vít Ondruch wrote:
>
>>
>> All three versions provide the same output, unless I did some mistake,
>> since I did not tested it (actually the middle one was taken directly
>> from rubygem-POpen4.spec). So which version you prefer? Please note that
>> the "gem install" will always "unpack" the gem with some additional, for
>> our case unimportant, steps. We do not distribute the .gem file
>> anywhere.
>
> You didn't exactly (directly) answer my question. Pretend I don't
> know much about ruby... (not far from the truth).
>
> So, for rubygem packages that include native (C or otherwise code),
> how and when is this compiled? If it is always done so during either
> version of these guidelines, please do accept my apologies for being
> ignorant.
It is compiled during the "gem install" step. So "gem install" is doing
%prep, %build, %install in one step. So yes, it is always done for
either version of guidelines.
>
> However, you do say you do not distribute the .gem, though I'm curious
> why this seem to contradict you:
>
> rpm -qlp rubygem-POpen4-0.1.4-3.fc17.noarch.rpm
> /usr/share/gems/cache/POpen4-0.1.4.gem
> ...
>
I knew you will point it out :).
It is cached version of the original gem, which RubyGems may use to
restore the gem into its original state (and may be other unknown
purposes). However, it is not used in runtime, nor it is good idea to
restore the gems maintained by RPM by gem command. Moreover, even though
the gem would not be available in the cache dir, RubyGems will download
it. Hence we add new clause into the packaging guidelines:
Since the Gem is installed using RPM, you *must* exclude the .gem file.
Vit
11 years, 3 months
Re: [Fedora-packaging] New packaging guidelines for Ruby
by Vít Ondruch
Dne 28.2.2012 17:27, Rex Dieter napsal(a):
> On 02/28/2012 10:13 AM, Vít Ondruch wrote:
>> Dne 28.2.2012 16:59, Rex Dieter napsal(a):
>>> On 02/28/2012 09:29 AM, Vít Ondruch wrote:
>>>>
>>>> Pleas do not be mistaken. We are not speaking about building gems from
>>>> sources.
>>>
>>> OK, so... is there some other better way to do it then? Please do
>>> suggest any better alternative if you do.
>>
>> Better way is not doing it.
>
> I guess we may have to agree to disagree then. Guidelines that allow
> for not building from (preferred form) source is deal-breaker for me
> at least.
May be you could elaborate a bit what do you want to achieve and what is
the reasoning. What do you mean by "not building from (preferred form)
source" anyway?
Vit
11 years, 3 months
Re: [Fedora-packaging] New packaging guidelines for Ruby
by Vít Ondruch
Dne 28.2.2012 16:59, Rex Dieter napsal(a):
> On 02/28/2012 09:29 AM, Vít Ondruch wrote:
>>
>> Pleas do not be mistaken. We are not speaking about building gems from
>> sources.
>
> OK, so... is there some other better way to do it then? Please do
> suggest any better alternative if you do.
Better way is not doing it. Only in exceptional cases. And the case
happened just once as far as I know (and I did rebuild of all gems in
Fedora, so I should know).
This was the original guidelines proposal [1] which builds upon
experiences with previous guidelines and extend/fixed them where it was
appropriate. I found it very sensitive, where mandatory gem rebuild is
definitely not.
Vit
[1]
https://fedoraproject.org/w/index.php?title=PackagingDrafts/Ruby&oldid=27...
>
> -- rex
> --
> packaging mailing list
> packaging(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging
11 years, 3 months
Re: [Fedora-packaging] New packaging guidelines for Ruby
by Vít Ondruch
Dne 28.2.2012 15:53, Rex Dieter napsal(a):
> On 02/28/2012 05:39 AM, Vít Ondruch wrote:
>
>> Yes, Ruby SIG is still against it, since there is known just one gem ATM
>> which needs such treatment. Now I list several pros/cons:
>>
>> Pros:
>> * It would allow ruby packages to follow the same steps as other
>> packages.
>>
>> Cons:
>> * More overhead for maintainers.
>> * More confusion for new-commers, since this approach is not know in
>> Ruby community and there is no best way how to achieve it.
>
> If this notion of building from source is not known in the ruby
> community, I'd highly recommend everyone (fpc, the ruby sig, etc...)
> help make them aware of how important that is.
Pleas do not be mistaken. We are not speaking about building gems from
sources. We are speaking about building from package manager output,
i.e. build gem from gem. It is like trying to rebuild RPM with some
applied patch from RPM (yes, I am not speaking about SRPM but about RPM
and that is not mistake). How will you do it? Yes, the RPM contains the
same metadata as there were in original spec + SRPM but how will you
reconstruct them? Would you suggest somebody to use this approach?
Vít
11 years, 3 months
New packaging guidelines for Ruby
by Vít Ondruch
Hi,
since I was not subscribed to this mailing list, I starting new thread
in Hope to move forward with the packaging guidelines. There are still
some outstanding issues.
= Mandatory rebuilding gems =
Yes, Ruby SIG is still against it, since there is known just one gem ATM
which needs such treatment. Now I list several pros/cons:
Pros:
* It would allow ruby packages to follow the same steps as other packages.
Cons:
* More overhead for maintainers.
* More confusion for new-commers, since this approach is not know in
Ruby community and there is no best way how to achieve it.
* There is only one known gem in Fedora, which needs this treatment ATM.
* If you need patch binary part of gem, it is sign that the gem is not
well maintained by upstream, otherwise it would not be needed.
= Vendorlib =
It is not good idea to move vendorlib out of the Ruby directory
structure. Actually it is pair of directories, vendorlib and
vendorarchlib. These directories are typically used by libraries Ruby
bindings, such as geos, subversion, etc. This platform dependent
bindings has no meaning to other Ruby implementations, such as JRuby.
= ruby(name) vs rubygems(name) =
Although we want to see as much libraries as possible provided in a gem
form, there still be some libraries which are not gemified. However,
Gemifies library *should not* always provide also ruby(name) virtual
provide, since these are not always simply interchangeable. Gem caries
with itself its metadata. When gem is loaded to Ruby's library path,
this metadata are processed as well and it might put some other
dependent libraries to Ruby's library path as well. In contrary, the
ruby(name) provide will mean that it is not gemified library, so I would
prefer to stay with distinction between ruby(name) and rubygem(name).
Gem would provide the ruby(name) only in case it obsoletes previously
available ruby library.
These are 3 concerns I remember was the most controversial. Please feel
free to share your thoughts.
Vít
11 years, 3 months
Migration from RSpec 1.3 to RSpec 2.x
by Vít Ondruch
Hi guys,
Since February, there are available RSpec 2.x in Fedora repositories.
However, as of now, the main package rubygem-rspec was not migrated to
RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
if we could finish the migration to RSpec 2.x lets say in F17 time
frame. What are your opinions? The list of packages which depends on
RSpec 1.3 is attached bellow.
If you wonder how to use RSpec 2.x for your package, it is usually quite
easy. In you spec just replace
BuildRequires: rubygem(rspec)
with
# Use rspec-core until rspec are migrated to RSpec 2.x
BuildRequires: rubygem(rspec-core)
and in you %check section, if you are not using Rake, replace call to
'spec' with 'rspec'. As an example, you can take a look on one of mine
rubygems, e.g. rubygem-regin, rubygem-pg.
Once we will migrate all packages into RSpec 2.x, we can migrate also
the rubygem-rspec and change the BR back to rubygem(rspec).
Vit
-------- Pu*vodní zpráva --------
Pr(edme(t: Re: aeolus conductor / rails 3 / F16 integration path
Datum: Tue, 12 Jul 2011 10:47:36 -0400
Od: Mo Morsi <mmorsi(a)redhat.com>
Komu: Vít Ondruch <vondruch(a)redhat.com>
> It is currently 24 packages which are using RSpec 1.x:
>
> ]$ repoquery --repoid=fedora-source --arch=src --whatrequires
> 'rubygem(rspec)'
> rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src (mmorsi)
> rubygem-boxgrinder-build-0:0.9.1-1.fc15.src (goldmann)
> rubygem-boxgrinder-core-0:0.3.1-1.fc15.src (goldmann)
> rubygem-commander-0:4.0.3-4.fc15.src (mfojtik)
> rubygem-cucumber-0:0.10.0-5.fc15.src (mmorsi, clalance, mfojtik)
> rubygem-cucumber-rails-0:0.3.2-5.fc15.src (mmorsi, clalance, mfojtik)
> rubygem-facon-0:0.4.1-2.fc15.src (stahnma)
> rubygem-factory_girl-0:1.3.2-3.fc15.src (mfojtik)
> rubygem-ffi-0:0.6.3-2.fc15.src (bkearney)
> rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
> rubygem-mail-0:2.2.15-2.fc15.src - upstream at 1.3.x (vondruch)
> rubygem-multimap-0:1.1.2-3.fc15.src - upstream at 1.3.x (mmorsi)
> rubygem-mustache-0:0.11.2-5.fc15.src - doesn't use RSpec at all. Seems to be wrong dependency (vondruch)
> rubygem-rack-test-0:0.5.4-1.fc15.src (mfojtik)
> rubygem-rake-compiler-0:0.7.8-1.fc15.src (mamoru)
> rubygem-regin-0:0.3.7-3.fc15.src - upstream at 2.x (vondruch)
> rubygem-rerun-0:0.5.2-4.fc15.src (mfojtik)
> rubygem-scruffy-0:0.2.6-2.fc15.src (mmorsi)
> rubygem-simple-navigation-0:3.0.0-3.fc15.src (mfojtik)
> rubygem-thin-0:1.2.7-2.fc15.src (mfojtik)
> rubygem-typhoeus-0:0.2.0-2.fc15.src (mfojtik)
> rubygem-uuidtools-0:2.1.1-1.fc14.src (mmorsi)
> rubygem-warden-0:1.0.3-4.fc15.src - upstream at 2.x (vondruch)
> rubygem-yard-0:0.5.3-3.fc14.src (mmorsi)
>
> So from my packages, 2 can be converted into RSpec 2.x right now, 2 are
> using 1.3, so it would need some effort and 1 seems to be just wrong
> dependency. May be we should move this discussion into ruby-sig ML
I appended the package owners onto the list for future reference.
Agree on moving this conversation to ruby-sig.
11 years, 3 months