In the process of rebuilding lots of gems for EL6, I've run across a a
couple areas where gems' test suites fail because of changes in Ruby's
hash ordering algorithms. I was able to apply upstream patches to fix
these issues in rubygem-activesupport and rubygem-activerecord. These
bugs are tricky t
Hi all,
I'm a newbie to Ruby and Gems packaging, and I was wondering about a
convention I see in the rubygem packages. I see Ruby Gems hardcode
specific version numbers, like "ruby(api) = 1.8", or "ruby(api) =
1.9.3"? In Perl modules we specify it like this:
Requires: perl(:MODULE_COMPAT_%(eval "
I have two more Ruby newbie questions :)
I see a lot of Gems contain a "Gemfile.lock" file. From looking at the
conventions in Fedora's packages, it's a good idea to not include the
Gemfile.lock in RPMs. I'm trying to understand how Gemfile.lock
relates to packaging.
General question: Is Gemfile.
On Thu, Apr 19, 2012 at 12:02 AM, Vít Ondruch wrote:
> Note that there was already some discussion about Bundler and packaging
> guidelines [2], but at the end, we did not found sound statement how to
> handle it correctly.
Thanks very much for your email. I read over your links several times
in
I'm wondering about how to handle things like the Rakefile, or /spec,
or /test directories in rubygem packages. My inclination is to leave
these out of the package to keep it slimmer, but I see that some
rubygems do include them in the package (or at least the -doc
subpackage). The example on the R
On Tue, Jul 17, 2012 at 12:09 PM, Mo Morsi wrote:
> +1. If you had any questions at anypoint don't hesitate to ask here
> (perhaps at some point it would make sense to create a #fedora-ruby IRC
> channel on freenode, what do ya'll think?)
Please do; I would join if we had one.
- Ken
On Thu, Jul 19, 2012 at 6:47 AM, Emanuel Rietveld wrote:
> Do we only update gems in rawhide?
Well, it seems like this is what Gem maintainers has been doing, at
least for the Fedora 17 cycle. Although, it seems to have been based
on necessity (given the large amount of upstream churn) rather tha
Hi Ruby SIG,
I'm interested in getting Gitorious into Fedora, and I've outlined the
steps necessary on the wiki [1]. I figured I would throw this out
there for feedback. I'm wondering if anyone see any other things to
consider along with what I've written?
Also, now that rubygem-ruby-net-ldap has
On Thu, Aug 9, 2012 at 2:57 AM, Vít Ondruch wrote:
> This was just rename from rubygem-ruby-net-ldap to rubygem-net-ldap as far
> as I remember. So it should be no problem.
Good deal. I later found out that upstream even has a patch in their
queue to follow this rename in their gemspec.[1]
> Oth
On Fri, Nov 2, 2012 at 8:24 AM, Darryl L. Pierce wrote:
> A note on specfile style: since we have a separate branch for each
> target version, you don't need to use the above conditional. Instead, on
> your el6 just use:
>
> Requires: ruby(abi) = 1.8
>
> and on F17+ us
>
> Requires: ruby(abi) = 1.
On Fri, Nov 30, 2012 at 10:07 AM, Dmitri Dolguikh wrote:
> #1 gets my vote.
Agreed, #1.
- Ken
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On Wed, Dec 19, 2012 at 5:35 AM, Vít Ondruch wrote:
> So how we can make every noarch ruby package compatible with both
> interpreters in terms of requires?
Could we just use a more complex comparison, like "greater or equal to
1.9.3, and less or equal to 2.0" ?
- Ken
___
Hi folks,
I was looking at the ruby-openid package, since it's a dependency for Gitorious:
https://admin.fedoraproject.org/pkgdb/acls/name/ruby-openid
Should this package be adjusted to use the RubyGem packaging
standards? ie. rename to rubygem-ruby-openid, use gem_ macros, etc.?
- Ken
On Wed, Feb 6, 2013 at 11:55 AM, Vít Ondruch wrote:
> I am not ruby-openid user, however, I would say that fedora can only benefit
> if ruby-openid is deprecated in favor of rubygem-ruby-openid. Not mentioning
> that the ruby-openid apparently did not received too much attention in
> recent years
I'm working on packaging rubygem-riddle and rubygem-thinking-sphinx.
Both gems are designed run the rspec test suites against a live MySQL
server.
Has anyone seen this before? Is it ok to try to do this in mock / koji?
- Ken
___
ruby-sig mailing list
ru
2:36 AM, Vít Ondruch wrote:
> Dne 15.2.2013 17:44, Ken Dreyer napsal(a):
>
>> I'm working on packaging rubygem-riddle and rubygem-thinking-sphinx.
>> Both gems are designed run the rspec test suites against a live MySQL
>> server.
>>
>> Has anyone seen this
On Fri, Mar 1, 2013 at 6:49 PM, Axilleas Pipinellis
wrote:
> So what are your thoughts? Any guidance, ideas or insights are very much
> appreciated!
Hi Axilleas,
I think this would be great. I'm working on Gitorious myself, and it
looks like Gitlab would share many dependencies. So that would ma
On Mon, Mar 11, 2013 at 9:27 AM, Vít Ondruch wrote:
> Please also note, that if you would specify BR: ruby(release), it would
> never happen that you could build your package in wrong target. May be we
> should clarify it in Guidelines, I am not sure.
+1 to this idea. This would solve the problem
On Thu, Mar 14, 2013 at 2:42 PM, Michael Stahnke wrote:
> I'd like to at least keep logic for EPEL 6 (and higher eventually).
> Puppet 2.6 which is in EPEL currently goes dead upstream at the end of
> April, so we'll have to do something there. I'm still weighing
> options for EPEL in general.
(
On Thu, Mar 28, 2013 at 3:11 PM, Dan Allen wrote:
> Is it possible to have
> an alias package in this case like in Debian where it will install
> rubygem-asciidoctor when you request asciidoctor?
I would love to see this for some other utility gems as well, like
"gem2rpm" or "puppet-lint". It wou
In looking over the release notes for Rails 4, it looks like it has a
hard requirement on Bundler. Is that the case?
I have been working on patching out Bundler's initialization from
Gitorious in preparation for packaging it, so that I could avoid the
problems associated with hard dependencies on
On Fri, Jul 26, 2013 at 7:54 AM, Mo Morsi wrote:
> The first rhgc.rb [1] extends the Fedora Gemfile checker I previously sent
> out to compare a local gemfile against a variety of other services including
> koji, distgit, bodhi, and more.
This script is really great. Thanks for publishing.
There
On Sun, Jul 28, 2013 at 1:20 PM, Axilleas Pipinellis
wrote:
> Hi,
>
> I am trying to package omniauth[0] and it fails when running
> the spec tests in mock. Using rpmbuild works fine.
>
> In particular it fails when calling rack/test, although the package
> is in BR and gets installed (as per the
I have packaged rubygem-acts-as-taggable for review:
https://bugzilla.redhat.com/1007635
It's got a few patches to build with Rails 4, but otherwise it's very
simple. I'm happy to trade a package review for this one.
- Ken
___
ruby-sig mailing list
ruby
jvcelak recently pointed out that the rubygems package does not own
/usr/share/gems/doc . This was news to me. I guess this changed
earlier this year:
commit 1d350ea912e72d30c7d079449db926ed4cb652a9
Author: TASAKA Mamoru
Date: Mon Feb 25 18:05:45 2013 +0900
Split out ri-generated documenta
aOn Mon, Nov 11, 2013 at 2:08 PM, Mo Morsi wrote:
> Also , be sure to checkout the gem_dependency_checker [4] repo
> which has received quite a few updates recently including support for
> updating a rpm spec to reflect the latest gem or Gemfile dependencies /
> files lists. There is still work le
On Fri, Nov 29, 2013 at 4:52 AM, Vít Ondruch wrote:
> Hi,
>
> Now I realized that I should not forgot to announce, that in RHEL 6.5 was
> released rubygems errata [1], which adds rubygems-devel subpackage with all
> rubygems macros you are used to already for several releases of Fedora.
This is r
It looks like Rails was recently broken in Rawhide when activesupport
and activemodel 4.0.2 went out a couple days ago.
Here's the bug against activesupport:
https://bugzilla.redhat.com/1040214 . (Later I discovered that
activemodel has a similar issue.)
To see the problem, try "yum install rubyg
Lots of gems ship dot files, like .gitignore or .travis.yml. These are
basically useless to users, and in our RPMs, we have to exclude these
files by hand.
The problem is that a lot of gems do something like this in the gemspec:
s.files = `git ls-files`.split("\n")
I end up repeating
I've submitted several gems up for review, and I'm happy to swap
package reviews with someone. These are all in the dependency chain
for Gitorious. [1]
http://bugzilla.redhat.com/1036901 - org-ruby
http://bugzilla.redhat.com/1037278 - resque-cleaner
http://bugzilla.redhat.com/1037900 - resqu
On Fri, Mar 21, 2014 at 10:18 AM, Mamoru TASAKA
wrote:
> Note that some packages (I maintain) already requires minitest 5 for
> testsuite (and
> currently I have to revert changes), e.g.
>
> http://pkgs.fedoraproject.org/cgit/rubygem-net-http-persistent.git/commit/?id=6f97361782c74f5da3117bc66fe1f
On Thu, Apr 3, 2014 at 1:31 AM, Vít Ondruch wrote:
> Dne 1.4.2014 12:46, Vít Ondruch napsal(a):
>> * I'd go with update to minitest 5 (probably tomorrow, unless you'll be
>> fast enough to point out some weak points ;)
>
> rubygem-minitest-5.3.1-1.fc21 is now available in Rawhide [1].
>
My first
On Wed, Apr 30, 2014 at 7:27 AM, Vít Ondruch wrote:
> The sidetag was merged back to rawhide. Please do *not* use the side-tag
> anymore and build for rawhide as you used to be.
Thanks very much to you, jstribny and mtasaka for the work on this. It
looks like you guys did the lions' share of the
On Sat, May 24, 2014 at 10:09 AM, Achilleas Pipinellis
wrote:
> Hello there!
>
> rubygem-hitimes [0] has been sitting lonely for some time now and I
> thought I'd give it a boost :)
>
> It's a new dependency for a gem I maintain (timers) and a stopper for a
> proper update.
>
> Thanks!
>
> [0] htt
It would be really nice to have yajl-ruby in Fedora. This gem blocks
Vagrant as well as Gitorious (
http://ktdreyer.fedorapeople.org/gitorious/graph.png) and I think
GitLab would be affected as well.
The review request has been open for a while:
https://bugzilla.redhat.com/show_bug.cgi?id=823351
On Tue, Jun 10, 2014 at 9:24 PM, Julian C. Dunn wrote:
> What's the accepted wisdom to fixing these? Disable tests on f21+?
> Convince upstream to upgrade? Both? Other suggestions?
There are a couple of approaches here.
The first step is to remove the "testrb" command and swap it for a
simple ru
I've got a gem (rubygem-virtus) that uses rspec/its in its test suite.
Is it worth packaging rubygem-rspec-its? Or is there a replacement
that virtus upstream ought to be using?
- Ken
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://adm
On Mon, Nov 10, 2014 at 7:32 AM, Vít Ondruch wrote:
> Dne 10.11.2014 v 14:59 Mamoru TASAKA napsal(a):
>> Hello, all
>>
>> After a long delay I finally pushed rspec 3.1.x into rawhide
>> (F-22) build tree. Also I pushed rubygem-rspec2 (and so on)
>> into rawhide tree.
>
> Thank you for the great wo
On Tue, Nov 18, 2014 at 10:08 AM, Vít Ondruch wrote:
> BTW I made a little script which can prepare an upstream tarball and
> update the ruby.spec a bit, not sure where to put it yet and what will
> be the future, so this is it at its temporary location:
>
> https://gist.github.com/voxik/8fa0593fa
On Mon, Oct 27, 2014 at 2:31 AM, Vít Ondruch wrote:
> Dne 27.10.2014 v 09:23 Vít Ondruch napsal(a):
>> As far as I understand, its should not be used at all:
>
> "its syntax" should read better :)
>
>
> Vít
>
>>
>> https://gist.github.com/myronmarston/4503509
>>
>> But not everybody is probably co
On Thu, Nov 27, 2014 at 10:30 AM, Ken Dreyer wrote:
> On Mon, Oct 27, 2014 at 2:31 AM, Vít Ondruch wrote:
>> Dne 27.10.2014 v 09:23 Vít Ondruch napsal(a):
>>> As far as I understand, its should not be used at all:
>>
>> "its syntax" should read
This looks like it would be a great resource for the Ruby SIG,
particularly with the tight version coupling I see in a lot of
gemspecs.
http://blog.famillecollet.com/post/2014/08/12/Koschei-continuous-integration-of-PHP-stack-in-Fedora
I see there are some ruby and gem packages here:
http://kosc
On Tue, Jan 6, 2015 at 7:03 AM, Dominic Cleal wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/01/15 13:53, Darryl L. Pierce wrote:
>> Have we decided to eliminate:
>>
>> Provides: rubygem(%{name}) = %{version}
>>
>> from the specfiles? I have an update for a gem I maintain and
>
On Tue, Jan 6, 2015 at 3:11 PM, Allen Hewes wrote:
>
> Could you provide a link or sample (like you did above)?. I'm interested... I
> need to be spoon fed sometimes. ;-)
Sure thing. Here's a patch where I only modified the package for Ruby
2.1 and Minitest 5:
http://pkgs.fedoraproject.org/cgit
On Tue, Jan 6, 2015 at 9:06 PM, Allen Hewes wrote:
>
> I have seen something similar (ruby -Ilib:test -e '...') to this in Fedora
> rubygem- packages. I don't quite understand why this would be done vs testrb
> or even use the gems' supplied method for running its' test suite (e.g. rake
> test).
On Wed, Jan 7, 2015 at 4:13 AM, Vít Ondruch wrote:
> Dne 7.1.2015 v 06:07 Ken Dreyer napsal(a):
>> To answer your question about why we just run "ruby -e
>> this-long-and-complicated-copypasta" instead of "testrb", see
>> https://lists.fedoraproject.or
On Mon, May 4, 2015 at 8:46 AM, Mamoru TASAKA wrote:
> By the way, I am not a maintainer of rubygem-rugged, either, and
> I don't use rubygem-rugged (currently). Anyway I want to know
> how the current maintainer think of the current status.
> If the current maintainer has no interest on this pack
On Mon, May 4, 2015 at 9:29 PM, Ken Dreyer wrote:
> On Mon, May 4, 2015 at 8:46 AM, Mamoru TASAKA
> wrote:
>> By the way, I am not a maintainer of rubygem-rugged, either, and
>> I don't use rubygem-rugged (currently). Anyway I want to know
>> how the current ma
On Thu, May 28, 2015 at 2:13 PM, Aditya Prakash
wrote:
> How
> important it is that gems I am using have rpm available? A good amount of
> development time will be wasted in packaging if this is a requirement.
I've had to take a break from Rails packaging for a while since I
switched jobs, but I
mock with dnf pulls in jruby to satisfy "Requires: ruby(release)" on
Rawhide. I've found that several (all?) of my local Rawhide mock
builds fail due to jruby issues. This makes maintaining gem packages
pretty tedious, and breaks fedora-review runs, etc.
Can we remove the "Provides: ruby(release)"
I haven't made time to dig into all my gems' FTBFS reasons in detail yet,
but the couple that I looked at appeared to be incompatibilities with the
latest rspec in rawhide. I've found that transpec is really useful for
fixing these. And the best part is that upstreams are usually open to
taking the
On Fri, Jan 15, 2016 at 9:26 AM, Mamoru TASAKA
wrote:
> Okay, now f24-ruby packages are tagged into f24.
> Big thank you for Vít, and thank you for all ruby folks.
Yes, thanks Vít!
- Ken
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
http:/
This sounds interesting, and I'm curious to see how well all the gems
build compared to the PyPI packages!
- Ken
On Fri, May 20, 2016 at 4:57 AM, Vít Ondruch wrote:
> Hi everybody,
>
>
> You probably noticed, that there is ongoing build of all Python packages
> in Copr [1] and today, I was appro
On Fri, May 27, 2016 at 12:48 PM, Vít Ondruch wrote:
> the
> packages in Copr will be converted to rpm by script, there won't be
> executed test suite, etc.
We could make gem2rpm gems run the test suites non-fatally, ie tack
"|| :" on to the end of the rspec or testrb invocations. That would at
On Fri, Mar 3, 2017 at 1:36 AM, Dan Allen wrote:
> Until this is fixed, my gem is going to fail in rawhide because I can't
> change the already released gem. I suspect there are others that are failing
> as well.
Dan, I've been thinking about this issue recently. It looks like
you're purposefully
This is really great. Thanks Vit!
On Fri, Aug 11, 2017 at 2:08 AM, Vít Ondruch wrote:
> Hi everybody,
>
> RPM 4.14.0 alpha was released yesterday [1] and it is already available
> in Rawhide [2]. Why I am writing this here? Because it will include
> support of .gem files by %setup macro. So final
56 matches
Mail list logo
