July 2012 - openSUSE Ruby - openSUSE Mailing Lists

[opensuse-ruby] Revised gem packaging
by Stephan Kulow 18 Dec '12

18 Dec '12

Hi, Want to know what I did for #hackweek8? I pulled ruby packaging apart and put it back together. I... - split ruby-common from the ruby package, so it can also be used from ruby 1.8 distros - added patched rpms to devel:languages:ruby:backports for older distros to support overwriting macros and ruby dependencies (11.4 and sle11) - enhanced the %gem_install macro - wrote a gemspec to rpm converter to have requires and provides in rpm automatic without gem2rpm run - changed the gem2rpm template heavily The key idea behind my work was that creating gem.rpm with gem2rpm is easy, updating is problematic (and over half the gems in dlre being outdated kind of proves my point :) So the new template has no requires and no provides, because rpm can find out both from the installed .gemspec. E.g. I found a couple of cases that left broken provides with an update (e.g. 0.8.X providing _0_7). But this strange suffixing is no longer necessary anyway. E.g. rails-3_2 has these automatic requires now: ruby(abi) = 1.9.1 rubygem(1.9.1:actionmailer) = 3.2.7 rubygem(1.9.1:actionpack) = 3.2.7 rubygem(1.9.1:activerecord) = 3.2.7 rubygem(1.9.1:activeresource) = 3.2.7 rubygem(1.9.1:activesupport) = 3.2.7 rubygem(1.9.1:bundler) >= 1.0 rubygem(1.9.1:bundler) < 2 rubygem(1.9.1:railties) = 3.2.7 No more bundler-1_0, but a simple bundler < 2. The automatic provides cover the old names, but I kind of hope we can drop them in the future: rubygem(1.9.1:rails) = 3.2.7 rubygem(rails) = 3.2.7 rubygem-rails = 3.2.7 rubygem-rails-3 = 3.2.7 rubygem-rails-3_2 = 3.2.7 rubygem-rails-3_2_7 = 3.2.7 I do not generate buildrequires in the template either, even though this is a rather tough call. We need buildrequires mainly to check that the dependencies are in the repo, but they create several problems: - gems build in "rings" and require a finished -> succeeded step for every ring, a rails update are 4 such rings. YOU GET CRAZY if the obs is busy! - you can't rely on automatism as the gem specificies "rails > 1.0", but there are 4 such rails versions and the build service wants to know which one you mean. And in case the rails version requires a rack > 1.1, it wants to know which one of those. YOU GET CRAZY! As gem packaging has to be 99% automatic to compete with out of rpm gem, I went for calling gem install with -f and ignore buildignores. To have a way to check dependencies in OBS, I created a small package called "all-good", that itself buildrequires all gems in the repository. That means for a rails update you will only need one ring: update all gems and then let the scheduler calculate if all-good can be expanded or if something misses dependencies. (all-good has a script to update the buildrequires if you had new gems) As some gems require specific but old versions of other gems, I created (DISCLAIMER: careful, do not read further if you're easy to upset) a package containing all those gems. This package will build rpms for all gems in the source directory. While fixing the current dependencies, I found 33 gems that I didn't feel worthy enough for their own spec file, so they ended up in d:l:r:e/all-the-others. It should be noted, that all the gems in there are of course tabu for factory submission. If you need a dependency in factory, create a spec file and dig out the license, gems are pretty bad in specifying the license in .gemspec, so most gem2rpm generated spec files have the CHECK(Ruby) license (even though most I found in practice have MIT). As digging out the license is pretty boring work you don't want to do another time when updating the package, I changed gem2rpm to take the license from the output file in case there is no license in the gemspec. This makes it possible to update to a newer version for gems pretty easy: gem2rpm *.gem -o *.spec. Whenever a spec file needs manual adaption, I add a MANUAL comment in there, so you spot in a diff very easy that you need to check e.g. an extra buildrequire or some file list manipulation. If the week had more days, I think I would put the whole %package and %files sections in a macro, so that we can (later) have ruby20 and ruby19 in parallel. If the requires are automatic and the buildrequires nonexistant, it's basically about the %files sections. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

7 78

[opensuse-ruby] Packaging schema.rb for rails applications
by Josef Reidinger 30 Jul '12

30 Jul '12

Hi, I now face one design issue we have in SLMS. We mark schema.rb as non-config and handle failed write during db:migration. I think that it is not good approach and schema.rb should contain correct state of database. How do you handle such situation? mark schema.rb as config or symlink somewhere in /var/lib? Ignore it? Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

3 2

[opensuse-ruby] Makeup mirror suppliers shared photos with you
by Makeup mirror suppliers 21 Jul '12

21 Jul '12

Dear: We have obtained your name and address from internet search,I know you sell fashion and promotion item,and we are writing to inquire whether you would be willing to establish business relations with us. We have been manufacturing promotion gift for many years now.our main products have makeup mirror,cosmetic brush,hair comb/brush,manicure sets, bottle opener,measuring tape etc.At present we are interested in extending our overseas market and would appreciate your respond. Considering our competitive prices and high quality,we expect to establish a long-term partnership With you. We look forward to your early reply. Thanks Best Regards! ------------------------------------ Ike Sale Manager Ningbo Yinzhou Victy Craft Factory

1 0

Re: [opensuse-ruby] Fwd: [obs submit-request 127033] openSUSE:Factory/puppet-dashboard:, declined by coolo
by Sascha Peilicke 17 Jul '12

17 Jul '12

Hi guys, From what I got from the discussion so far is that shipping bundled gems in-tree instead of using packages seems to help mostly the packager in that he doesn't have to fiddle with all the masses of ever-changing / don't-look-backwards gems du jour. Studio seems to have made their experiences with that, altough I think ~200 bleeding-edge-n-monkey-patching-everything gems are just a maintenance nightmare in any form, be it packages or bundles gems. OBS broke due to behavior changes even in patch-level gem updates. As we don't have the time to look at every commit in every gem, we are rather conservative with introducing new gem dependencies (or updating old ones). As long as we can upstream gem fixes, I see no real problem with bundled gems (besides our packaging policies maybe). But how about SUSE-specific gem patches that are not upstreamable / rejected? Do you branch gems on github and use those instead of upstream ones? What about SUSE-confidential changes, e.g. for SLE (if there are any)? I think this would remain an issue even if zypper would support gems (which would be great). Using packages certainly has an advantage here. @James: How does Studio handle such situations? However, I don't really see anybody except SUSE products actually using (or more precisely 'caring for') packaged gems for the same reasons we struggle with them. The Ruby community just doesn't care and probably never will, enterprise (or 'stable') isn't a fancy word in the webby world. So we should either bribe Ryan Bates to not present fancy new gems anymore or we do just what suits ourselves. Actually, we (as in coolo, adrian & me) only touch gems/packages if OBS (and maybe software-o-o) needs it. Studio seems to use the same approach when it comes to devel:languages:ruby:extensions. Therefore, openSUSE mostly went the Ruby-1.9 / Rails-3.2 road with packaged gems and doesn't care for anything else anymore. As Studio won't be shipped with / supported by openSUSE any time soon, openSUSE would just gain nothing by shipping Studio's gem dependencies (or even caring for compatibility). Thus openSUSE should retain its current policies. As long as the security and maintenance teams are ok, the Studio team should continue doing whatever suits it and it's customers best. But again, you should really try to keep the fancyness level low. OBS already depends on far (far far far) to many gems (hey, it's Rails and it's supposed to be cool), but 200+ for Studio just seems like screaming madness to me. Linking dynamically or statically to 200 C libraries would be calling for trouble too! BTW. sorry for not replying to the thread, I just subscribed and Thunderbird doesnt' allow to inject "In-Reply-To" in the compose view :-) -- Viele Grüße, Sascha Peilicke

4 8

[opensuse-ruby] Fwd: [obs submit-request 127033] openSUSE:Factory/puppet-dashboard: declined by coolo
by Stephan Kulow 16 Jul '12

16 Jul '12

Hi, I declined this because IMO we shouldn't allow rails apps with bundled gems in factory. It's fine in whatever project, but there is no point in packaging gems if all apps then just call bundle package. What do you think? Does this make sense? Is that realistic? Greetings, Stephan -------- Original-Nachricht -------- Betreff: [obs submit-request 127033] openSUSE:Factory/puppet-dashboard: declined by coolo Datum: Thu, 5 Jul 2012 08:27:45 +0000 Von: coolo(a)suse.com Antwort an: coolo(a)suse.com An: coolo(a)suse.com State of submit-request #127033 was changed by coolo: review -> declined Comment: this package contains copies of all gems, this is not how openSUSE packages work I think. And it requires ruby(abi) = 1.8, which does not exist on factory https://build.opensuse.org/request/diff/127033 Source project: systemsmanagement:puppet package: puppet-dashboard revision: 1 Target: project: openSUSE:Factory package: puppet-dashboard -- Hermes messaging (http://hermes.opensuse.org) openSUSE Build Service (https://build.opensuse.org/) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

3 6

[opensuse-ruby] couchdb broken
by James Tan 12 Jul '12

12 Jul '12

Hi, Not sure if this is the right list, but couchdb is broken: https://build.opensuse.org/package/show?package=couchdb&project=server%3Ada…. Is someone fixing this? Thanks, James T. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

1 1

[opensuse-ruby] Failing rubygem-ohai for factory
by James Tan 11 Jul '12

11 Jul '12

Hi, The rubygem-ohai package that was working fine last week now fails to build in Factory. Any ideas why? https://build.opensuse.org/package/live_build_log?arch=i586&package=rubygem… Thanks, James T. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

2 2

[opensuse-ruby] [RUG-N] Tomorrow evening @ SUSE HQ
by Dominik Bamberger 03 Jul '12

03 Jul '12

[German version below] Hey everybody, RUG-N (Ruby User Group Nuremberg) meets tomorrow evening at SUSE's HQ in Nuremberg. Since there was very little non-German participation the last times, I'll only say so much in English: If you are interested in Ruby and want to meet other people that are alike, please join us tomorrow at 7pm @ Maxtorhof. ==== German (extended) version ==== Ahoi Ruby-Freunde, ich werde zukünftig keine weiteren Einladungen zur Ruby User Group Nürnberg (RUG-N) auf diese Mailing Liste posten. Da wir uns morgen Abend aber im SUSE HQ in der Maxfeldstraße treffen, wollte ich alle die nicht eh schon Bescheid wissen, hiermit nochmals herzlichst einladen. Wir treffen uns ab 19:00 Uhr in der All-hands Area des Maxtorhofs. Themen haben wir auch diesmal wieder zwei am Start: Einerseits erzählt uns Henning Koch von der makandra GmbH etwas über bizarre Berechtigungsprobleme und deren Lösungen. Andererseits werde ich zeigen, wie man Pull Requests (auf GitHub) schon vorab testen kann. Wenn Ihr auch zukünftig auf dem Laufenden bleiben wollt, dann solltet Ihr Euch ein Lesezeichen auf unsere Homepage http://rug-n.de setzen oder dank der Infos, die Ihr dort findet, userer Google Group beitreten oder unserem Twitter Feed folgen. Bis bald, Dominik / Bamboo PS: Natürlich dürft Ihr diese Mail gerne weiterleiten. ;-) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

1 0