[RFC] Multiple source repositories per-chunk and git submodule handling
by Richard Maw
We currently handle definitions that need to pull multiple source
repositories together in an ad-hoc way.
For gcc we import the gmp, mpc and mpfr source trees in by checking them
into our delta branch directly.
Some upstreams handle importing the sources by adding submodules.
However, we have to make them fetch sources from our Trove for
reproducibilty and latency concerns, so we end up having to add a delta
on top to change where the submodules fetch their sources from.
This works against one of our goals for minimising the delta, so we
need a way to encode in our builds how to deal with components that need
sources from multiple repositories to function.
Our current approach from submodules introduces a _lot_ of extra work
when we need to update multiple submodules recursively, so we need a
better solution.
Proposal
========
To solve this, I propose we extend the source repository information from
just (repo, ref) to be a list [(repo, ref, path?, ?submodule-commit)].
So rather than:
name: base
⋮
chunks:
- name: foo
morph: strata/base/foo.morph
repo: upstream:foo
ref: cafef00d…
unpetrify-ref: baserock/morph
⋮
build-depends: []
We extend it to be able to take a "sources" field.
⋮
chunks:
- name: foo
morph: strata/base/foo.morph
sources:
- repo: upstream:foo
ref: baserock/morph # used to validate commit is anchored
# properly and as a hint for where
# you ought to merge changes to
commit: cafef00d…
- repo: delta:gnulib
commit: deadbeef…
ref: baserock/GNULIB_0_1_2
path: .gnulib # where to put the cloned source
submodule-commit: feedbeef… # check that this matches, so you
# can be told if you need to update
# your delta
⋮
The `path` field is used to specify that this tree should be placed in
the parent tree at this position.
The `path` field is optional, defaulting to `.`
If multiple paths, after normalising, clash, then it results in a
build-failure at source creation time.
Sub-sources can be placed over an empty directory, when there's no
existing entry at that path, or when there's a git submodule there AND
the commit of the submodule matches the `submodule-commit` field.
If there's a file, symlink, non-empty directory or submodule that doesn't
match `submodule-commit` there, then it results in a build-failure
at build-time.
The `submodule-commit` check exists as a safeguard against the parent
repository being updated and requiring a new version, which your specified
commit isn't appropriate for.
If you get a build fail because the submodule isn't appropriate then
you have to check whether the version you specify works, then update
the commit.
Cache key changes
=================
This shouldn't require any cache key changes to existing definitions,
but builds that make use of multiple source repositories will also hash
the commit tree and path.
Alternative solutions for submodules
====================================
We could continue to use the current model, and deal with the pain of
having to make multiple branches in multiple repositories to satisfy
the change to the repository paths.
We could have a magic look-up table to replace repository urls when we
parse the submodules.
We could use git-replace to magically make git do the url correction, but
then we'd have to handle replacements properly, rather than dropping them.
7 years, 6 months
Which system-version-manager to use for "--json" arg?
by James Thomas
Hi,
Was trying to upgrade my jetson using master of definitions, however the
deployment was failing on the label check,
system-verison-manager list --json
I tried using the system-version-manager from tbdiff master, however I still get
system-version-manager: error: unrecognized arguments: --json
What's the correct version of system-version-manager to use here?
I worked around it for now by removing the label check in ssh-rsync.write
--
Thanks
James
7 years, 8 months
Research on exporting build definitions from other build tools
by Sam Thursfield
Hi all
I spent the last couple of weeks, along with Pedro, doing some research
on exporting from
This ties in with the idea that it would be great if build/integration
instructions weren't all tied to specific tools. We have part of the
puzzle solved already: the current Baserock reference definitions are
usable by 2 totally separate tools. There's still lots of room for
improvement in the Baserock definitions format ... and one way of
improving it is to try to represent existing instructions from *other*
build/integration efforts, using our supposedly general-purpose
definitions format.
We won't be able to produce working, useful, readable, maintainable
definitions this way, in most cases. But it can still inform our data
model; for example, many build/integration tools track runtime
dependency information in their data model, which suggests that any
generic data model for build/integration will need to track them
This all sounds quite grand, but actually what I have to show you is
some wiki links and a really nasty patch for BitBake :-)
BitBake recipes
---------------
Turns out you can turn BitBake recipes into working shell + Python
scripts, which effectively 'flattens' the data and makes it easier to
represent them generically. There is *lots* of context and many
hardcoded paths, so consider this a 'view' onto the data, rather than
something you could work on and maintain.
It would be interesting to take this further, and try to 'distill' key
information like source code location (SRC_URI), or the configure
commandline. This would be best done by post-processing the exported
shell & Python files, I think ... perhaps tweaking the base .bbclass
files to add special markers would be useful, too.
For example, in base.bbclass, base_do_fetch() could add some commentted
marker that would expand to '#@#@# source-code-location: git://foo/bar"
in the generated .py script, which a post-processing script could then
easily find when scannning all the generated output. And any package
that had overridden the base 'do_fetch' task wouldn't have that marker,
highlighting that it was doing something non-standard to fetch its
source code.
Read more about that here:
http://wiki.baserock.org/projects/importing-from-bitbake/
There is a (rather dry) video of me doing this export:
https://www.youtube.com/watch?v=gW1NKZPomjI
I also sent the patch to bitbake-devel, pointing out that it's just a
proof of concept / ugly hack at this point, to see if readers of that
list could give any feedback or pointers:
http://lists.openembedded.org/pipermail/bitbake-devel/2015-August/006297....
Nix derivations
---------------
Pedro's NixOS research is here:
<http://wiki.baserock.org/projects/importing-from-nixos/>. It seems that
he got as far as discovering there are lots of circular dependencies,
which prevented actually extracting much information so far.
I had a quick look for how NixOS bootstraps itself; it seems to be
defined here:
<https://github.com/NixOS/nixpkgs/blob/6a3b25dbd3e1f3a7257bc34e97d51254392...>.
Looks like a 5 stage bootstrap process, that rebuilds some packages at
each stage, so perhaps the key to resolving the circular deps is to
distinguish between the different instances of these packages?
Debian/Ubuntu packages
----------------------
I was pointed towards Germinate, a tool to deal with Debian 'seeds'. It
returns dependency information, but not much else -- no build instructions.
I also tried 'dgit', which provides a neat wrapper over the Debian
archive. However, it seems to require SSH access to a machine at
debian.org which I don't have, so I guess the tool is only useful for
people who actually maintain packages, at least for now.
In general I think Debian and Ubuntu will be the least fruitful area for
this kind of research, because there is so much diversity in the way
packages are built that it would really timeconsuming to try to extract
information from all the different places it might be.
I'm away for the next two weeks. Please feel free to ask questions about
this research on this mailing list, and I'll answer once I'm back.
Sam
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
7 years, 8 months
Generic cache server: the revenge
by Sam Thursfield
Hi
I was discussing what the quickest route would be to get
cache.baserock.org to accept artifacts submissions from the wider world,
and not just from the private network that it's on. With specifically an
atomic 'push' method that would work well for the YBD 'controllerless'
distributed build approach that Paul has been investigating.
For historical reasons, cache.baserock.org is currently a Trove instance
that isn't really a Trove. But in order to get something running as
quickly but neatly as possible, with new features, I think this would be
the approach:
- Add a '/2.0/submit' method to morph-cache-server that accepts artifact
as HTTP PUT data.
- Make this method put the artifact in /home/cache/artifacts in a
subdirectory named for the artifact, which is a neat way of making the
PUT be atomic: subsequent pushes will fail because they can't overwrite
the directory
- Teach the /files method to look inside these directories for files as
well as in /home/cache/artifacts itself
- Pick a base OS to deploy this on (debian, fedora or a baserock 'build'
system would probably all work)
- Write an Ansible script to install morph-cache-server from Git, and
HTTPS proxy tool (haproxy), configure morph-cache-server and the proxy
to run at boot. See trove-setup.git for how to do most of this (but it
can be a lot simpler than that).
- Set up the proxy to authenticate access to the /2.0/submit method. I'm
no expert on how to do this, but I'd suggest requiring client-side SSL
certificates. This might help:
https://raymii.org/s/tutorials/haproxy_client_side_ssl_certificates.html
These instructions are incomplete, it's just an idea of an approach for
solving this that would hopefully be quick, and make the infrastructure
team (or at least, me) very happy.
I would be happy to replace the current cache.baserock.org with
something like the thing described above. We already have some machines
at baserock.org which are defined in infrastructure.git simply as
Ansible scripts to run on top of a given distribution. For example..
..the mail relay:
http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/infrastructure...
..the frontend haproxy system:
http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/infrastructure...
Lauren already did some work on morph-cache-server recently, I don't
know where it is pushed to, but it would probably be worth starting from
there.
Hope this helps anyone who is interested in doing this :-)
Sam
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
7 years, 8 months
Building armv7 on aarch64
by James Thomas
Hello,
Here's how to go about building armv7lhf images on aarch64 using a chroot. I
used ybd for this since there's still a small issue with the aarch
* Download an armv7 devel image (e.g jetson)
* Mount this and extract the rootfs
mkdir /src/armv7chroot
mount /path/to/jetson.img /mnt
cp -r /mnt/systems/default/run/* /src/armv7chroot
* Create a script in /src/armv7chroot
#!/bin/bash
cd /src/armv7chroot
cp /etc/resolv.conf etc/
mount -o bind /dev dev/
mount -o bind /proc proc/
mount --bind . . && chroot .
* Now launch it with linux32
/usr/bin/linux32 -B /src/armv7chroot/launch.sh
Now you can follow the normal baserock build process. I had to use ybd for the
build since the aarch is reported as:
armv8l GNU/Linux
So morph still thinks you're trying to cross compile, however with ybd you can
just do
ybd.py systems/devel-system-jetson-armv7lhf.morph armv7lhf
and everything is hunky dory. The devel system builds in 4 hours and 30 minutes
(not including download time) so seems to be pretty quick, I'll repeat the same
test on a jetson though (it's been a while since i've built from scratch there)
Next Steps
----------
* In morph treat armv8 as whatever the arch is in the system you are build, if
that is armv7*
* Start releasing armv7lhf chroot's so we can use baserock-manager-chroot (looks
like we'll need to add schroot to baserock?)
I might be able to volunteer an armv8 mustang which could then be used as an
armv7 mason, so we can start populating the public arm cache's again, I'll have
to check this since it's not mine, but it has been sat on my desk for some time
gathering dust.
--
Thanks
James
7 years, 9 months
Migrations problem since commit 2b5e86290672 of definitions.git
by Sam Thursfield
Hi
I went to run the migration script for definitions version 6 and found
that it crashes with an assertion failure in ruamel.yaml.
It seems that this is a bug in ruamel.yaml that was triggered by commit
2b5e86290672 of definitions.git.
I've sent a pull request that fixes the issue and makes the migration
work again; it's currently here:
https://bitbucket.org/ruamel/yaml/pull-requests/4/fix-assertion-failure-f...
Once that patch is reviewed I'll send a patch to update the version of
ruamel.yaml that we use in the Baserock reference systems. This mail is
just to save time for anyone who runs the migration scripts in the
meantime and wonders why they don't work !
Sam
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
7 years, 9 months
Proposal for Baserock definitions format version 7
by Sam Thursfield
Hi again
As promised, I've looked at how we can move the predefined build-system
command sequences, and predefined artifact splitting rules, into
definitions.git. This has several advantages:
- We can change the 'reference' defaults without having to define a
new version of the Baserock definitions format every time we do it.
- Anyone working in a given definitions.git repo can easily change or
extend the defaults for that repo.
- Less stuff needs to be hardcoded in build tools and parsers.
I propose the following approach: add a file named DEFAULTS to the top
level of the definitions repo, which is a YAML document with a set
structure.
The migration linked below illustrates how I imagine DEFAULTS will look
for the Baserock reference system definitions.
- Migration for definitions v7, plus JSON-Schema description of the
DEFAULTS file: https://gerrit.baserock.org/1012
- Proposed patch for Morph:
https://gerrit.baserock.org/1018/
- Proposed patch for YBD:
https://github.com/ssssam/ybd/commit/07805911dd8df0073f848ac4246e1dfb0cb5...
Please let me know what you think, using the medium of +1s, -1s, or even
full sentences. The patches haven't had masses of testing yet, help with
that is appreciated.
Note that I'm away for a couple of weeks so I won't be chasing this up
further until mid to late August, although I can probably respond to
questions on the mailing list during that time. Feel free to finish it
off and merge it all in my absence! :)
Sam
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
7 years, 9 months
Baserock 15.34 is released!
by Pedro Alvarez
# Baserock 15.34 is released!
For an online version of this notes, please visit:
<http://wiki.baserock.org/releases/baserock-15.34>
## Definitions compatibility
The Baserock reference systems are defined using version 5 of
the definitions format. In 15.25, version 3 was used.
The baserock-15.34 tag of definitions can be built with Morph
from 15.25. This should mean upgrading is fairly simple.
The version of Morph in Baserock 15.34 can build definitions
versions 3, 4, 5, and 6. For more information about these
versions, see here:
<http://wiki.baserock.org/definitions>
## Changes since 15.25
* This release includes a GENIVI Kronos K-0.2 Baseline.
* Added migrations scripts, and established some guidelines
for writing migration scripts. Check the
[README](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/defini...
file for more information about these.
* Numerous components moved between strata.
* New components added:
- GNU wget
- samba
* Some components have been updated:
- cpython to 2.7.10 (python 2) and 3.4.2 (python 3)
- perl to 5.22
- libsoup to 2.48.0
* Updates to Morph, Baserock's build tool, including:
- Support for definitions version 6 (disable build system
autodetection, and add support to specify the build system
within a stratum).
- Various distbuild fixes and improvements.
- Set chunk commands' stdin to /dev/null.
- Added 'bitbucket' repo alias to default aliases.
- Warn if system-integration commands are defined for an unknown artifact
* Other bugfixes and improvements: see the Git logs of
[definitions.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/basero...
and
[morph.git](http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/mor...
for a full list.
Thanks to everyone who has provided code, documentation, sponsorship or
feedback for this Baserock release!
# How do I get started?
Start with the following page: <http://wiki.baserock.org/quick-start/>
Those who are up to speed with Baserock already can make use of the
'cache.baserock.org' cache server, with the `artifact-cache-server =
http://cache.baserock.org:8080/` option. All artifacts necessary to
upgrade a 'build' system for x86_32 or x86_64 are present in this
cache.
# How do I get in contact?
- IRC: freenode #baserock
- Public mailing list: baserock-dev(a)baserock.org
- See also: <http://wiki.baserock.org/mailinglist/>
If you find a bug in Baserock, we'd like to hear from you using one of
the above methods.
The Baserock project welcomes new participants! We hope you enjoy
experimenting with Baserock and look forward to hearing about any cool
things you do with Baserock.
--
Pedro
7 years, 9 months
'does not point to a valid object!' errors while cloning from git.baserock.org
by Paul Sherwood
Hi all,
while running ybd today I noticed quite a few errors from
git.baserock.org (see below). Is this normal, or do we need to do some
cleanup?
br
Paul
15-08-20 05:47:10 [lorry-controller] Try fetching tarball
git___git_baserock_org_baserock_baserock_lorry_controller.tar
Connecting to git.baserock.org (185.43.218.183:80)
wget: server returned error: HTTP/1.1 404 Not Found
tar: git___git_baserock_org_baserock_baserock_lorry_controller.tar:
Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
15-08-20 05:47:10 [lorry-controller] Try git clone from
git://git.baserock.org/baserock/baserock/lorry-controller
Cloning into bare repository
'/src/gits/git___git_baserock_org_baserock_baserock_lorry_controller.tmp'...
remote: Counting objects: 1807, done.
remote: Compressing objects: 100% (861/861), done.
remote: Total 1807 (delta 1223), reused 1357 (delta 939)
Receiving objects: 100% (1807/1807), 303.86 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1223/1223), done.
Checking connectivity... done.
15-08-20 05:47:13 [lorry-controller] Git repo is mirrored at
/src/gits/git___git_baserock_org_baserock_baserock_lorry_controller
15-08-20 05:47:13 [lorry-controller] Cache_key is
lorry-controller.f6a57042a707e96c0b1aa065cda8b904b6b3a35a942fb0eea5984b4ef4e8d90a
15-08-20 05:47:13 [lorry-controller] Cache_key is
lorry-controller.cfb0b3a5db0173f7eb83fb30398e8acdbe1370f129e2b7429a4d1ccf89966b3d
15-08-20 05:47:13 [lua] WARNING: no tree from cache-server
948063437e0350d9ef1649ec3a76d0c24a5c8642
15-08-20 05:47:13 [lua] Try fetching tarball
git___git_baserock_org_delta_lua.tar
Connecting to git.baserock.org (185.43.218.183:80)
git___git_baserock_o 100%
|*******************************************************************************************************************************************************|
2679k 0:00:00 ETA
remote: Counting objects: 143, done.
remote: Compressing objects: 100% (90/90), done.
remote: Total 143 (delta 53), reused 117 (delta 41)
Receiving objects: 100% (143/143), 820.30 KiB | 746.00 KiB/s, done.
Resolving deltas: 100% (53/53), completed with 12 local objects.
From git://git.baserock.org/delta/lua
* [new ref] refs/gitano/admin -> refs/gitano/admin
* [new branch] Linux-i686 -> Linux-i686
* [new branch] Linux-x86_64 -> Linux-x86_64
* [new branch] baserock/5.1-morph -> baserock/5.1-morph
* [new branch] new_dist_structure -> new_dist_structure
* [new branch] static -> static
* [new tag] 5.1.5-Linux-i686 -> 5.1.5-Linux-i686
* [new tag] 5.1.5-Linux-x86_64 -> 5.1.5-Linux-x86_64
* [new tag] 5.2-Linux-x86_64 -> 5.2-Linux-x86_64
* [new tag] 5.2.1-Linux-i686 -> 5.2.1-Linux-i686
* [new tag] 5.2.1-Linux-x86_64 -> 5.2.1-Linux-x86_64
* [new tag] 5.2.2-Debian-i686 -> 5.2.2-Debian-i686
15-08-20 05:47:19 [lua] Git repo is mirrored at
/src/gits/git___git_baserock_org_delta_lua
15-08-20 05:47:19 [lua] Cache_key is
lua.89143d92468c48ff88aef77bff1ba796c02a764cf9b549b5f6cc37160768d3e6
15-08-20 05:47:19 [lace] WARNING: no tree from cache-server
d1b540b6d361d6a1f51e53cdaab69f053340efbb
15-08-20 05:47:19 [lace] Try fetching tarball
git___git_baserock_org_delta_gitano_lace.tar
Connecting to git.baserock.org (185.43.218.183:80)
git___git_baserock_o 100%
|*******************************************************************************************************************************************************|
134k 0:00:00 ETA
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
remote: Counting objects: 21, done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 21 (delta 5), reused 18 (delta 3)
Unpacking objects: 100% (21/21), done.
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
From git://git.baserock.org/delta/gitano/lace
* [new ref] refs/gitano/admin -> refs/gitano/admin
* [new branch]
baserock/danielsilverstone/upgrade-gitano-fix-rsync ->
baserock/danielsilverstone/upgrade-gitano-fix-rsync
* [new branch] baserock/morph -> baserock/morph
error: refs/gitano/oldadmin does not point to a valid object!
15-08-20 05:47:20 [lace] Git repo is mirrored at
/src/gits/git___git_baserock_org_delta_gitano_lace
15-08-20 05:47:20 [lace] Cache_key is
lace.da8ff6e517fd56c2470fd68aeb297bd47f0c337950bdd8db3f4d79a5a8872e63
15-08-20 05:47:20 [luxio] WARNING: no tree from cache-server
be9d125080b9ff2376273e21b75669b65dc88d46
15-08-20 05:47:20 [luxio] Try fetching tarball
git___git_baserock_org_delta_luxio.tar
Connecting to git.baserock.org (185.43.218.183:80)
git___git_baserock_o 100%
|*******************************************************************************************************************************************************|
239k 0:00:00 ETA
remote: Counting objects: 27, done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 27 (delta 8), reused 24 (delta 5)
Unpacking objects: 100% (27/27), done.
From git://git.baserock.org/delta/luxio
* [new ref] refs/gitano/admin -> refs/gitano/admin
* [new branch] baserock/morph -> baserock/morph
15-08-20 05:47:21 [luxio] Git repo is mirrored at
/src/gits/git___git_baserock_org_delta_luxio
15-08-20 05:47:21 [luxio] Cache_key is
luxio.912b8c001ec881dcccb40fbdc50f42234b0ae2c24682d37e86f4e63a58b38cf9
15-08-20 05:47:21 [supple] WARNING: no tree from cache-server
0963e5706d78d0ae7446ea91af986de1e196eb39
15-08-20 05:47:21 [supple] Try fetching tarball
git___git_baserock_org_delta_gitano_supple.tar
Connecting to git.baserock.org (185.43.218.183:80)
git___git_baserock_o 100%
|*******************************************************************************************************************************************************|
98304 0:00:00 ETA
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 1), reused 3 (delta 0)
Unpacking objects: 100% (4/4), done.
From git://git.baserock.org/delta/gitano/supple
* [new branch] baserock/morph -> baserock/morph
* [new branch] diagnosis -> diagnosis
15-08-20 05:47:21 [supple] Git repo is mirrored at
/src/gits/git___git_baserock_org_delta_gitano_supple
15-08-20 05:47:21 [supple] Cache_key is
supple.7b7b2aff5198e884a8816bfa6d3536db9332e46ee583671ad8460f70a93db5ec
15-08-20 05:47:21 [clod] WARNING: no tree from cache-server
da15894f42f48d15db997c4355d6b672371a4163
15-08-20 05:47:21 [clod] Try fetching tarball
git___git_baserock_org_delta_gitano_clod.tar
Connecting to git.baserock.org (185.43.218.183:80)
git___git_baserock_o 100%
|*******************************************************************************************************************************************************|
63488 0:00:00 ETA
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 19 (delta 4), reused 18 (delta 3)
Unpacking objects: 100% (19/19), done.
From git://git.baserock.org/delta/gitano/clod
+ e637f91...fa835f9 refs/gitano/admin -> refs/gitano/admin (forced
update)
* [new branch] baserock/morph -> baserock/morph
15-08-20 05:47:21 [clod] Git repo is mirrored at
/src/gits/git___git_baserock_org_delta_gitano_clod
15-08-20 05:47:21 [clod] Cache_key is
clod.bd9df16d8847a67bc55b1bcb574cf95ed3cf79ba21276668cf55de5c957aec8b
15-08-20 05:47:21 [gall] WARNING: no tree from cache-server
f58c7526fbb0421d7f5446644f01f4cf57035ee2
15-08-20 05:47:21 [gall] Try fetching tarball
git___git_baserock_org_delta_gitano_gall.tar
Connecting to git.baserock.org (185.43.218.183:80)
git___git_baserock_o 100%
|*******************************************************************************************************************************************************|
124k 0:00:00 ETA
remote: Counting objects: 27, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 27 (delta 13), reused 16 (delta 6)
Unpacking objects: 100% (27/27), done.
From git://git.baserock.org/delta/gitano/gall
+ c465380...fb663cf refs/gitano/admin -> refs/gitano/admin (forced
update)
* [new branch] baserock/danielsilverstone/update-gall ->
baserock/danielsilverstone/update-gall
* [new branch] baserock/morph -> baserock/morph
* [new branch] merge-base-regression -> merge-base-regression
* [new branch] replace-luagit2 -> replace-luagit2
15-08-20 05:47:23 [gall] Git repo is mirrored at
/src/gits/git___git_baserock_org_delta_gitano_gall
15-08-20 05:47:23 [gall] Cache_key is
gall.4ba7cf993873f6b8c8c582654011a7928ee9f9e6df60a2dc48cf8b42645379c3
15-08-20 05:47:23 [lrexlib-pcre] WARNING: no tree from cache-server
0524a6e3ab6d50cba63c8642a875e246de53d651
15-08-20 05:47:23 [lrexlib-pcre] Try fetching tarball
git___git_baserock_org_delta_lrexlib.tar
Connecting to git.baserock.org (185.43.218.183:80)
git___git_baserock_o 100%
|*******************************************************************************************************************************************************|
705k 0:00:00 ETA
remote: Counting objects: 18, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 18 (delta 7), reused 13 (delta 4)
Unpacking objects: 100% (18/18), done.
From git://git.baserock.org/delta/lrexlib
* [new ref] refs/gitano/admin -> refs/gitano/admin
* [new branch] baserock/morph -> baserock/morph
15-08-20 05:47:24 [lrexlib-pcre] Git repo is mirrored at
/src/gits/git___git_baserock_org_delta_lrexlib
15-08-20 05:47:25 [lrexlib-pcre] Cache_key is
lrexlib-pcre.358563ee59803bc855b107cb9b6819b18865b80308c4ca60b35ad840b6b5cb49
15-08-20 05:47:25 [gitano] WARNING: no tree from cache-server
4b8ce6875266fdd6609a217dcf2924d7d4815cc2
15-08-20 05:47:25 [gitano] Try fetching tarball
git___git_baserock_org_delta_gitano_gitano.tar
Connecting to git.baserock.org (185.43.218.183:80)
git___git_baserock_o 100%
|*******************************************************************************************************************************************************|
480k 0:00:00 ETA
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
remote: Counting objects: 472, done.
remote: Compressing objects: 100% (224/224), done.
remote: Total 472 (delta 265), reused 444 (delta 243)
Receiving objects: 100% (472/472), 54.04 KiB | 0 bytes/s, done.
Resolving deltas: 100% (265/265), completed with 18 local objects.
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
error: refs/gitano/admin does not point to a valid object!
error: refs/gitano/oldadmin does not point to a valid object!
From git://git.baserock.org/delta/gitano/gitano
* [new ref] refs/gitano/admin -> refs/gitano/admin
* [new branch] baserock/danielsilverstone/S10632-plugin-support
-> baserock/danielsilverstone/S10632-plugin-support
* [new branch] baserock/danielsilverstone/S10633-repo-detection
-> baserock/danielsilverstone/S10633-repo-detection
* [new branch] baserock/danielsilverstone/S10634-rsync-support ->
baserock/danielsilverstone/S10634-rsync-support
* [new branch]
baserock/danielsilverstone/upgrade-gitano-fix-rsync ->
baserock/danielsilverstone/upgrade-gitano-fix-rsync
* [new branch] baserock/liw/new-lc-2 -> baserock/liw/new-lc-2
* [new branch] baserock/master -> baserock/master
* [new branch] baserock/morph -> baserock/morph
* [new branch] baserock/pedroalvarez/openstack-trove2 ->
baserock/pedroalvarez/openstack-trove2
* [new branch] baserock/pedroalvarez/trove-ansible3 ->
baserock/pedroalvarez/trove-ansible3
* [new branch] baserock/richardipsum/cgis ->
baserock/richardipsum/cgis
* [new branch] baserock/richardipsum/gitano_http ->
baserock/richardipsum/gitano_http
* [new branch] baserock/richardipsum/http ->
baserock/richardipsum/http
* [new branch] baserock/richardipsum/http_br ->
baserock/richardipsum/http_br
* [new branch] baserock/richardipsum/http_v2 ->
baserock/richardipsum/http_v2
* [new branch] baserock/richardipsum/http_v3 ->
baserock/richardipsum/http_v3
* [new branch] baserock/richardipsum/http_v3_br ->
baserock/richardipsum/http_v3_br
* [new branch] baserock/richardipsum/log_emerg ->
baserock/richardipsum/log_emerg
* [new branch] baserock/richardipsum/stringbuf ->
baserock/richardipsum/stringbuf
* [new branch] baserock/richardipsum/syslog ->
baserock/richardipsum/syslog
* [new branch] dsilvers/add-commands -> dsilvers/add-commands
* [new branch] dsilvers/revamp-patterns ->
dsilvers/revamp-patterns
* [new branch] dsilvers/testing -> dsilvers/testing
* [new branch] http-updates -> http-updates
* [new branch] liw/gitano-setup-manpage ->
liw/gitano-setup-manpage
* [new branch] supple-integration -> supple-integration
error: refs/gitano/oldadmin does not point to a valid object!
15-08-20 05:47:26 [gitano] Git repo is mirrored at
/src/gits/git___git_baserock_org_delta_gitano_gitano
15-08-20 05:47:26 [gitano] Cache_key is
gitano.8ad5cec1776b70b08fd81c1ad5128ec0ceb8938263f04cb64eec1fe45d2b30bf
15-08-20 05:47:26 [cgit] WARNING: no tree from cache-server
acbf4a15e260c711094455dbef7c024f2553fd32
15-08-20 05:47:26 [cgit] Try fetching tarball
git___git_baserock_org_delta_cgit.tar
Connecting to git.baserock.org (185.43.218.183:80)
git___git_baserock_o 100%
|*******************************************************************************************************************************************************|
1543k 0:00:00 ETA
remote: Counting objects: 174, done.
remote: Compressing objects: 100% (127/127), done.
remote: Total 174 (delta 113), reused 89 (delta 44)
Receiving objects: 100% (174/174), 60.53 KiB | 0 bytes/s, done.
Resolving deltas: 100% (113/113), completed with 49 local objects.
From git://git.baserock.org/delta/cgit
* [new ref] refs/gitano/admin -> refs/gitano/admin
* [new branch] baserock/morph -> baserock/morph
* [new branch] jk/follow-renames -> jk/follow-renames
* [new branch] jk/http-status-codes -> jk/http-status-codes
* [new branch] stable -> stable
* [new branch] upstream/jd/zx2c4-deployment ->
upstream/jd/zx2c4-deployment
* [new branch] upstream/jk/follow-renames ->
upstream/jk/follow-renames
* [new branch] upstream/jk/valgrind-tests ->
upstream/jk/valgrind-tests
* [new branch] upstream/lh/grep -> upstream/lh/grep
* [new branch] upstream/lh/pretty-blob-view ->
upstream/lh/pretty-blob-view
* [new branch] upstream/master -> upstream/master
* [new branch] upstream/wiki -> upstream/wiki
* [new branch] upstream/wip -> upstream/wip
* [new branch] wip -> wip
* [new tag] larsh-public-key -> larsh-public-key
15-08-20 05:47:51 [cgit] Git repo is mirrored at
/src/gits/git___git_baserock_org_delta_cgit
15-08-20 05:47:51 [cgit] Cache_key is
cgit.e1f35569271ddb42b89127b2af1bac4df0ae80ea3c315d357c3aa046fec7fc33
15-08-20 05:47:51 [trove-setup] WARNING: no tree from cache-server
16de74536e0846ba1d2e5101618df9146c785a41
15-08-20 05:47:51 [trove-setup] Try fetching tarball
git___git_baserock_org_baserock_baserock_trove_setup.tar
Connecting to git.baserock.org (185.43.218.183:80)
wget: server returned error: HTTP/1.1 404 Not Found
tar: git___git_baserock_org_baserock_baserock_trove_setup.tar: Cannot
open: No such file or directory
tar: Error is not recoverable: exiting now
15-08-20 05:47:51 [trove-setup] Try git clone from
git://git.baserock.org/baserock/baserock/trove-setup
Cloning into bare repository
'/src/gits/git___git_baserock_org_baserock_baserock_trove_setup.tmp'...
remote: Counting objects: 876, done.
remote: Compressing objects: 100% (541/541), done.
remote: Total 876 (delta 437), reused 445 (delta 221)
Receiving objects: 100% (876/876), 122.42 KiB | 0 bytes/s, done.
Resolving deltas: 100% (437/437), done.
Checking connectivity... done.
15-08-20 05:47:54 [trove-setup] Git repo is mirrored at
/src/gits/git___git_baserock_org_baserock_baserock_trove_setup
15-08-20 05:47:54 [trove-setup] Cache_key is
trove-setup.28088322f77a110b821f194dc195ca0c2e6420967cd09bb1f20cc9387f5b8cc2
15-08-20 05:47:54 [lua-scrypt] WARNING: no tree from cache-server
0d7f74cd3eab7d54fbb13294194de7ea70ac34a5
15-08-20 05:47:54 [lua-scrypt] Try fetching tarball
git___git_baserock_org_delta_lua_scrypt.tar
7 years, 9 months
