Am 13.06.2006 um 21:36 schrieb Richard Purdie:
On Tue, 2006-06-13 at 11:49 -0700, Tim Bird wrote:
I have the same problem using OE from inside a
corporate environment. Does anyone have a
solution for cvs/svn/mtn access from behind a firewall?
I've been thinking of possible solutions, and right now
all I can think of is to create a web-based proxy service
for the various fetch routines. (And, of course, keep
such a proxy service up and running on a relatively
speedy link). CELF could host the service, I suppose.
Is anything like this already being done? I see some
references to check_for_tarball() in the cvs, svk and svn
fetch modules - are these doing some kind of local check
for sources?? If so, maybe there just needs to be a method
to pre-populate the tarball stash?
OE already has all the code needed to take cvs, svn and git checkout
tarballs from a mirror server (CVS_TARBALL_STASH). It also generates
these tarballs as part of its build process. All you'd need to do is
have a server running "bitbake xyz -c fetch" outside the firewall to
generate the tarballs and then the internal server having access to
these tarballs by pointing at them with the CVS_TARBALL_STASH
variable.
oesources.org was one attempt to do this to reduce load on CVS and SVN
servers. The tricky bit is managing the tarballs so you don't run
out of
disk space!
After reading this I threw my own answer away and add some additional
information to this mail instead. BitBake offers the
SRC_TARBALL_STASH (used to be named CVS_TARBALL_STASH) which will be
utilized when using svn, svk, cvs, and git. Additionally in
base.bbclass we have a regular expresion of mirrors for HTTP based
sources.
Our options are making oesources.org work again and doing regular
snapshots again, or to create a new and better oesources, which does
not run out of diskspace as it removes old snapshots.
And sadly Chris Larson pointed out bitbake xyz -cfetch is broken in
regard to the RDEPENDS handling. E.g. bitbake opie-image -cfetch will
not fetch too many source packages. I assume this will be fixed
within the next week.
And the '404' you see is the attempt to get a snapshot from the
oesources.org snapshot mirror, so it is no failure but simply the
missing shortcut.
For OpenEmbedded itself we have http://www.openembedded.org/repo/
which could be the last resort if only HTTP is working. It is planned
to provide readonly subversion trees of the OpenEmbedded metadata as
well.
regards
h.
PS: If CELF can help with any of the above issues I think everyone
here would be glad
_______________________________________________
Oe mailing list
[email protected]
https://www.handhelds.org/mailman/listinfo/oe
