| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Conflicts:
baserockimport/app.py
|
|
|
|
|
|
| |
Content overlaps with that of the README a bit, I'm not sure what to do
about this. Putting 'man' pages online as part of our continuous
delivery infrastructure should ultimately be the goal.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The multi_json Gem wasn't being detected as signed, because the
'signing_key' field is an expression that can evaluate to 'nil' in some
cases. In this Gem the 'cert_chain' field was still a standard string.
Hopefully checking for the presence of either will catch all cases
(and false positives should be harmless anyway).
|
| |
|
| |
|
|
|
|
|
| |
This was motivated by <https://github.com/mislav/will_paginate>, which
links to <https://github.com/mislav/will_paginate/wiki> as its homepage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously if we got a BaserockImportException which contained a '%' in
the message, you'd see this...
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cliapp/app.py", line 190, in
_run
self.process_args(args)
File "/src/import/baserockimport/app.py", line 102, in process_args
super(BaserockImportApplication, self).process_args(args)
File "/usr/lib/python2.7/site-packages/cliapp/app.py", line 539, in
process_args
method(args[1:])
File "/src/import/baserockimport/app.py", line 185, in import_rubygems
loop.run()
File "/src/import/baserockimport/mainloop.py", line 176, in run
self.app.status(str(e), error=True)
File "/src/import/baserockimport/app.py", line 105, in status
text = msg % args
TypeError: not enough arguments for format string
|
|
|
|
|
|
| |
The rubygems.to_chunk tool was assuming the .gemspec file always lived
at the top of the chunk repo, but this isn't the case for
<https://github.com/rails/rails>. Now it is smarter.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This isn't a perfect fix. If this situation occurs the tool will
generate an invalid stratum and the user will need to rename one of
the chunks. But this is a better than what would have happened before:
one of the chunks would have been silently ignored.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now the tool gives the filenames of both files involved in the conflict.
The most likely reason for seeing this error is that, at least in
the lorries.git on git.baserock.org[1], the toplevel directory contains
some 'disabled' subdirectories, so the user needs to point --lorries-dir
to the correct subdirectory so that duplicate disabled lorries aren't
loaded.
This isn't really the final word on that problem, because having the
tool load disabled lorries is quite bad and if there are no conflicts
the user won't notice that it's happening and other confusing stuff
might occur. But hopefully it's good enough for now.
1. http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/tree/
|
|\ |
|
| |
| |
| |
| |
| | |
You often want the latest stable rather than whatever is Git master,
which usually doesn't even import cleanly!
|
| |
| |
| |
| |
| | |
I think this makes the output a bit clearer to follow. Maybe. It's hard
to know these things until it's too late.
|
| |
| |
| |
| |
| |
| | |
I think this makes it clearer what the tool is actually doing, and
hopefully makes it clearer what the user should do in cases where the
tool couldn't determine which ref to use and reports an error.
|
| |
| |
| |
| |
| |
| |
| | |
This is used to ignore Gems which either come built into Ruby (like
Rake) or are supplied with the 'ruby' stratum. As noted in the comment
in the .yaml file it is not an ideal solution, but it should work well
enough for the time being.
|
| |
| |
| |
| |
| | |
Sometimes this is due to weird version requirements caused by some other
package which isn't actually needed.
|
| |
| |
| |
| | |
This is cool because now you can import Ruby on Rails.
|
| | |
|
| |
| |
| |
| |
| | |
This should be useful when a couple of components raise errors but
you know that you don't need them anyway.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By calling Bundler::Dsl.gemspec without specifying :path, this tool
was causing the Bundler::Source::Path instance for the target .gemspec
to be for path '.', which is relative path that is only valid inside
one Dir.chdir block. It seems that all the Bundler resolution code runs
inside that block and so there should be no problem, but unless we
specify an absolute path for the gemspec then errors like this sometimes
appear:
/usr/lib/ruby/gems/2.0.0/gems/bundler-1.7.6/lib/bundler/resolver.rb:357:in
`resolve': Could not find gem 'ffi-yajl (>= 0) ruby' in source at ..
(Bundler::GemNotFound)
Source does not contain any versions of 'ffi-yajl (>= 0) ruby'
This normally happens when an Omnibus import chains to rubygems.to_chunk
for a RubyGem component.
The path is clearly valid at the time Bundler::Dsl.gemspec is called
(otherwise it'd raise a Bundler::InvalidOption exception at the time)
but not valid later (hence the error). Note that the second '.' in that
error message is a full stop and not part of the path!
|
| |
| |
| |
| |
| |
| | |
Previously it was hardcoded to just look for rubygems deps, which has
an obvious flaw. It now looks for all types of dependencies that were
enabled with enable_importer().
|
| |
| |
| |
| |
| |
| |
| | |
It's now in the 'ruby' stratum, so the import tool can ignore it.
The build-dependency-whitelist field is now empty, and I'm not sure
it's actually useful to have it but I won't remove the code yet.
|
|/
|
|
|
|
|
| |
This avoids a situation where `bundle install` expects a bunch of stuff
to exist in /usr or /home but you have since moved the repo around.
Installing stuff in /usr is not recommended in Baserock because it gets
lost on upgrades (and /usr will one day be read only, I expect).
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was caused by a mistake in:
commit c8e156fe181c8e62fda9f9a999af1f0a0980a0ce
Author: Sam Thursfield <sam.thursfield@codethink.co.uk>
Date: Mon Nov 17 17:20:00 2014 +0000
Don't force the generated stratum through morphloader validation
We should be able to trust it, since we literally just generated it.
|
|\
| |
| |
| | |
Thanks to Richard Maw for finding most of these issues.
|
| | |
|
| |
| |
| |
| | |
There's no need for quite so many subshells.
|
| |
| |
| |
| | |
We should be able to trust it, since we literally just generated it.
|
|/ |
|
|
|
|
|
|
|
|
| |
Code for this was taken from Morph's setup.py file.
It would possibly be more correct to install these files into a
subdirectory of /usr/libexec but it'd be a more complex solution for
little actual benefit.
|
|
|
|
| |
Now data/ actually gets installed too.
|
| |
|
|
|
|
|
|
|
| |
If we create the definitions-dir we also initialise it as a Git repo,
now.
I also deleted a no-longer-needed hack.
|
| |
|
|
|
|
|
| |
This version of the import tool requires morph.git commit
6779e46e880eec757a6923441accef2442007677 or newer.
|
|
|
|
|
|
| |
It's slightly annoying during development, but the exts/ must be inside
the package or it would be installed somewhere silly like
/usr/lib/python2.7/site-packages/exts.
|
| |
|
| |
|
|
|
|
| |
Finally the repo starts to look a little more tidy!
|
| |
|
|
|
|
|
|
|
| |
Use \ for multiline strings in Ruby instead of +.
Change 'raise Exception' to just 'raise', because Exception is the
default type.
|
| |
|