GitHub

Comments and changes to this ticket

• 

  defunkt June 13th, 2008 @ 11:39 PM

  • → Assigned user changed from “” to “PJ Hyett”
• 

  PJ Hyett June 14th, 2008 @ 01:43 AM

  • → State changed from “new” to “open”

  What specifically did you add and what was the warning?

  Thanks,

  PJ

• 

  Matthew King June 14th, 2008 @ 03:30 PM

  Warning was:

  WARNING: no rubyforge_project specified

  I added "rubyforge_project = 'functor'" to the Gem::Specification.

• 

  PJ Hyett June 14th, 2008 @ 07:11 PM

  Warnings shouldn't prevent the gem from building, did dyoder receive a PM with the build error?

  I've made a few modifications to the build system recently that allows gems to be built that were being disallowed previously. It's probably worth dyoder trying to build another gem.

• 

  Matthew King June 16th, 2008 @ 01:10 AM

  gem build was failing for dyoder/functor. I forked his project and, noticing a warning in the local build process, added a rubyforge_project attribute.

  Updated gemspec, pushed changes, and the gem got built for my fork.

  Is the GitHub gem builder failing on warnings, or perhaps on lack of rubyforge_project specifically?

  Thanks, y'all.

• 

  PJ Hyett June 23rd, 2008 @ 02:00 AM

  The builder shouldn't fail on warning, this is strange. Is it possible he missed something simple like forgetting to check the "RubyGem" box?

• 

  Matthew King June 23rd, 2008 @ 04:10 PM

  I am reasonably sure the RubyGem box was checked. I will see about reproducing this with another project and report if I find anything.

• 

  Eric Mill June 29th, 2008 @ 11:25 PM

  • → Tag changed from “” to “gem”

  I just had a similar issue with my project 'basecamper'. The gem installed by Github had marked the executable in the gem's executable directory (/bin/basecamper.rb) with permissions 733, meaning it was missing read permissions for group and user. I marked it with 777 and I was able to run the gem fine.

• 

  Eric Mill June 29th, 2008 @ 11:46 PM

  My last comment had a few mistakes in it and could be better. Let me try again.

  I just had a similar issue with my project 'basecamper'. The gem installed by Github ("Klondike-basecamper") had marked the executable in the gem's executable directory ($GEM_PATH/gems/basecamper-1.0.2/bin/track) with permissions 733, meaning it was missing read permissions for group and user. Consequently, the binary in /usr/bin couldn't perform 'load "track"'. I marked $GEM_PATH/gems/basecamper-1.0.2/bin/track as 777 and I was then able to run "track" fine from the command line.

  So, I think there's something about Github's gem repackager that installs binaries with incorrect file permissions.

• 

  Eric Mill June 30th, 2008 @ 03:52 PM

  I was mixing up issues I guess, my issue belongs on http://logicalawesome.lighthouse... , and I commented there.

• 

  PJ Hyett July 29th, 2008 @ 08:14 AM

  • → State changed from “open” to “wontfix”

  closing this since i haven't heard of this happening elsewhere