[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.
8 years
[PATCH 0/6] Firehose Implementation
by Lauren Perry
Hi all,
Back in November I sent to the list an RFC for Firehose. This preliminary patch series demonstrates the current work I have done, based on the pre-existing prototype Firehose, and the steps taken towards automating this process.
Currently, Firehose is not fully automated; there are still a number of steps that need to be performed manually, such as setting up a Firehose user, enabling the firehose.service and firehose.timer files and installing the firehose shell for general use. These steps are demonstrated in firehose.configure (prelim) and I will post a follow up patch with a README demonstrating steps that need to be taken currently.
Firehose will also need a Gerrit user configured with an appropriate set of ssh keys to access Gerrit.
A Firehose machine has been demonstrated to work properly on OpenStack, though it requires the firehose command to be done manually.
Regards,
Lauren
Lauren Perry (6):
Add tools for installing Firehose and its dependencies
Add systemd styled timers to automate Firehose checking process
Removed morph after placing its functionality in firehose.sh
Modify firehose email configuration and push location to ensure
commits are pushed to the testgerrit server with an appropriate
commit message and branch name
Install githook to add Change-Id value to commit message
Add firehose.configure, containing the necessary instructions to run
firehose
firehose.configure | 39 ++++++++++++++++++++++++++
firehose.service | 12 ++++++++
firehose.sh | 21 ++++++++++++++
firehose.timer | 11 ++++++++
{plugin => firehose/plugin}/firehose_plugin.py | 20 +++++++++----
morph | 17 -----------
setup.py | 16 +++++++++++
7 files changed, 113 insertions(+), 23 deletions(-)
create mode 100644 firehose.configure
create mode 100644 firehose.service
create mode 100755 firehose.sh
create mode 100644 firehose.timer
rename {plugin => firehose/plugin}/firehose_plugin.py (92%)
delete mode 100755 morph
create mode 100644 setup.py
--
1.8.4
--
1.7.10.4
8 years, 6 months
[PATCH 0/9 v3] Implement Mason with Zuul and turbo-hipster
by Michael Drake
sha1: b7c98ed9bf83c703846965144156a91fa2ebd0b3
repo: ssh://git@git.baserock.org/baserock/baserock/definitions.git
branch: baserock/tlsa/mason2
This patch series adds Zuul, turbo-hipster and their dependencies
to definitions and creates a Mason system containing them. It uses
mason.configure to insert some configuration files and set up some
SSH keys and the like. An Ansible playbook runs on boot which
fills in the template configuration files and starts the Zuul and
turbo-hipster services that are required.
It is important to note that there is some configuration that needs
to be done to the Gerrit instance you wish to deploy this against.
Namely, you will need to create a Mason user, add a Verified label
and allow the Mason user to vote on that label, and add the required
SSH key to the Mason user.
It has only been tested using OpenStack, as it is understood that
is how the Baserock project intends to use it.
Most of this work was originally done by Adam Coldrick, and is based
on his branch at baserock/adamcoldrick/zuul-mason-v2. I have done
a few fixes, rebased it on a more recent master of definitions and
attended to previous review comments.
Adam Coldrick (5):
Move Paramiko into its own stratum from Ansible
Add a system for Mason
Make mason.configure install the new Mason config
Add an example cluster morphology for mason
Add a README for mason
Michael Drake (4):
Fix tar to build with acl in foundation stratum.
Add a stratum for Zuul, turbo-hipster and their dependencies
Add a stratum for the tests used by Mason
Update python-prettytable.
.../mason-system-x86_64-openstack-deploy.morph | 55 +++++
mason.configure | 140 +++++++-----
mason.configure.help | 127 +++++++++++
mason/README | 120 ++++++++++
mason/ansible/mason-setup.yml | 129 +++++++----
mason/{httpd.service => lighttpd.service} | 2 +-
mason/mason-generator.sh | 101 ---------
mason/mason-report.sh | 252 ---------------------
mason/mason.service | 10 -
mason/mason.sh | 93 --------
mason/mason.timer | 10 -
mason/share/lighttpd.conf | 21 ++
mason/share/mason.conf | 14 --
mason/share/os.conf | 1 -
mason/share/turbo-hipster-config.yaml | 47 ++++
mason/share/zuul-layout.yaml | 22 ++
mason/share/zuul-logging.conf | 44 ++++
mason/share/zuul.conf | 26 +++
mason/ssh-config | 2 +
mason/turbo-hipster.service | 10 +
mason/zuul-merger.service | 10 +
mason/zuul-server.service | 10 +
strata/baserock-ci-tests.morph | 14 ++
strata/baserock-ci-tests/system-tests.morph | 5 +
strata/python-common.morph | 4 +-
strata/python-paramiko.morph | 24 ++
strata/python-paramiko/pycrypto.morph | 3 +
strata/webtools/tar.morph | 11 +-
strata/zuul-ci.morph | 137 +++++++++++
systems/mason-system-x86_64-generic.morph | 58 +++++
30 files changed, 901 insertions(+), 601 deletions(-)
create mode 100644 clusters/mason-system-x86_64-openstack-deploy.morph
create mode 100644 mason.configure.help
create mode 100644 mason/README
rename mason/{httpd.service => lighttpd.service} (69%)
delete mode 100755 mason/mason-generator.sh
delete mode 100755 mason/mason-report.sh
delete mode 100644 mason/mason.service
delete mode 100755 mason/mason.sh
delete mode 100644 mason/mason.timer
create mode 100644 mason/share/lighttpd.conf
delete mode 100644 mason/share/mason.conf
create mode 100644 mason/share/turbo-hipster-config.yaml
create mode 100644 mason/share/zuul-layout.yaml
create mode 100644 mason/share/zuul-logging.conf
create mode 100644 mason/share/zuul.conf
create mode 100644 mason/ssh-config
create mode 100644 mason/turbo-hipster.service
create mode 100644 mason/zuul-merger.service
create mode 100644 mason/zuul-server.service
create mode 100644 strata/baserock-ci-tests.morph
create mode 100644 strata/baserock-ci-tests/system-tests.morph
create mode 100644 strata/python-paramiko.morph
create mode 100644 strata/python-paramiko/pycrypto.morph
create mode 100644 strata/zuul-ci.morph
create mode 100644 systems/mason-system-x86_64-generic.morph
--
2.1.4
8 years, 7 months
[PATCH 0/4 v2] Put Mason's test code in the system-tests repo
by Michael Drake
sha1: 7fb68b7f377583dac40634338870583baaa2fe65
repo: ssh://git@git.baserock.org/baserock/baserock/system-tests.git
branch: baserock/mason-v2
This copies the scripts/release-* scripts from definitions into system-tests
and reworks them to run as turbo-hipster jobs.
These turbo-hipster jobs are example jobs which may be used by version 2
of mason, which is a gerrit-driven zuul/turbo-hipster based automated testing
system that tests candidate branches before merging them to master.
While the existing tests from definitions are reused here, we may choose
to replace them or augment them with other different tests.
Most of this work was originally done by Adam Coldrick, and there were
some fixes from Sam Thursfield. I have taken the work from where Adam
left off (branch: baserock/adamcoldrick/mason-tests-v2) and done some
fixes, and improvements based on testing and previous review comments.
Adam Coldrick (2):
Put the existing code into trove-upgrades
Add a Zuul job runner.
Michael Drake (2):
Import code from the baserock definitions release-* scripts.
Add mason 'build', 'test' and 'upload' as Zuul plugins
mason/__init__.py | 5 +
mason/deployment.py | 272 +++++++++++++++++++++
mason/publishers.py | 256 +++++++++++++++++++
mason/runners.py | 161 ++++++++++++
mason/tests/__init__.py | 3 +
mason/tests/artifact_upload.py | 112 +++++++++
mason/tests/build.py | 128 ++++++++++
mason/tests/build_test.py | 188 ++++++++++++++
mason/util.py | 145 +++++++++++
config.py => trove-upgrades/config.py | 0
.../test_trove_upgrades.py | 0
util.py => trove-upgrades/util.py | 0
12 files changed, 1270 insertions(+)
create mode 100644 mason/__init__.py
create mode 100644 mason/deployment.py
create mode 100644 mason/publishers.py
create mode 100644 mason/runners.py
create mode 100644 mason/tests/__init__.py
create mode 100644 mason/tests/artifact_upload.py
create mode 100644 mason/tests/build.py
create mode 100644 mason/tests/build_test.py
create mode 100644 mason/util.py
rename config.py => trove-upgrades/config.py (100%)
rename test_trove_upgrades.py => trove-upgrades/test_trove_upgrades.py (100%)
rename util.py => trove-upgrades/util.py (100%)
--
2.1.4
8 years, 7 months
[PATCH] Remove stddef.h include to fix build with musl
by Richard Dale
repo: git://git.baserock.org/delta/syslinux
branch: baserock/rdale/musl
commit: 2b71aa376b6ebf1b99116c9b0c407267e84fb036
target: baserock/morph
---
memdump/argv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/memdump/argv.c b/memdump/argv.c
index ca41e03..2f36913 100644
--- a/memdump/argv.c
+++ b/memdump/argv.c
@@ -33,7 +33,6 @@
*/
#include <stdint.h>
-#include <stddef.h>
#include <stdio.h>
#define ALIGN_UP(p,t) ((t *)(((uintptr_t)(p) + (sizeof(t)-1)) & ~(sizeof(t)-1)))
--
1.9.1
8 years, 8 months
[PATCH 0/2] Fix build of openssh with musl
by Richard Dale
These two patches fix building openssh with musl.
repo: git://git.baserock.org/delta/openssh-git
branch: baserock/rdale/musl
commit: 84e25ab50fbcb787bd1e72de1eb920d8590c2ff5
target: baserock/morph
Richard Dale (2):
Fix incorrect use of 'ut' struct
Add a sys/param.h include to compile with musl
loginrec.c | 10 +++++-----
sshd.c | 1 +
2 files changed, 6 insertions(+), 5 deletions(-)
--
1.9.1
8 years, 8 months
[PATCH 00/18] Use OSTree when caching artifacts
by Adam Coldrick
Hi all,
This patch series first adds support for using a union filesystem when
constructing systems and also when deploying systems. It also adds an artifact
cache which uses OSTree to store chunk and system artifacts and modifies the
rest of the code to make use of this cache. System artifacts are stored as
a tree containing only the files modified at system construction time, greatly
reducing the size of the artifact.
This provides speedups wherever we were previously unpacking things from
tarballs, especially when doing `morph deploy`. I don't have any numbers to
show the size of the speedups at the moment, I will send some out tomorrow
once I've had time to run some tests.
Note that this patch series requires you to have OSTree and its dependencies
in your system, along with at least one of overlayfs or unionfs-fuse. See
my other patch series (Add overlayfs, FUSE, OSTree and dependencies) for
further information/patches to definitions.
Thanks,
Adam
Repo: git://git.baserock.org/baserock/baserock/definitions
Ref: baserock/adamcoldrick/use-ostree-for-artifact-cache
SHA: 0b2179480920e2ae1ddd1dcd8f12427c8bd4ec78
Target: master
Adam Coldrick (18):
Allow the passing of options to fsutils.mount
Use overlayfs when building systems
Use overlayfs when deploying
Add support for unionfs-fuse
Create device nodes in staging area
Move the chunk cache logic into buildcommand
bins: We no longer want chunks to be tarballs
Add a class to wrap the OSTree API
Add an artifact cache which uses OSTree
RemoteArtifactCache: Support multiple cache methods
Make morph use OSTreeArtifactCache instead of LocalArtifactCache
builder: Use the OSTree artifact cache when building
deploy: Use OSTree to checkout the system for deployment
gc: Make `morph gc` use the OSTree artifact cache
morph-cache-server: Add support for an OSTree artifact cache
yarns: Make the distbuild yarn expose the worker's artifact cache
over HTTP
yarns: Disable the cross-bootstrap yarn
cmdtests: We can no longer meaningfully look at chunks in the cache
morph-cache-server | 115 ++++++-----
morphlib/__init__.py | 2 +
morphlib/app.py | 7 +
morphlib/bins.py | 61 +++---
morphlib/bins_tests.py | 100 +---------
morphlib/buildcommand.py | 32 ++-
morphlib/builder.py | 118 ++++++-----
morphlib/builder_tests.py | 18 +-
morphlib/fsutils.py | 25 ++-
morphlib/ostree.py | 139 +++++++++++++
morphlib/ostreeartifactcache.py | 229 ++++++++++++++++++++++
morphlib/plugins/deploy_plugin.py | 76 +++++--
morphlib/plugins/gc_plugin.py | 10 +-
morphlib/remoteartifactcache.py | 27 ++-
morphlib/stagingarea.py | 58 +++---
morphlib/stagingarea_tests.py | 41 ++--
morphlib/util.py | 6 +-
ostree-repo-server | 15 ++
tests.build/build-chunk-writes-log.script | 38 ----
tests.build/build-stratum-with-submodules.script | 8 +-
tests.build/build-stratum-with-submodules.stdout | 3 -
tests.build/build-system-autotools.script | 7 +-
tests.build/build-system-autotools.stdout | 3 -
tests.build/build-system-cmake.script | 7 +-
tests.build/build-system-cmake.stdout | 2 -
tests.build/build-system-cpan.script | 7 +-
tests.build/build-system-cpan.stdout | 1 -
tests.build/build-system-python-distutils.script | 12 +-
tests.build/build-system-python-distutils.stdout | 6 -
tests.build/build-system-qmake.script | 10 +-
tests.build/build-system-qmake.stdout | 8 -
tests.build/build-system.script | 27 ---
tests.build/build-system.stdout | 5 -
tests.build/cross-bootstrap.script | 5 +-
tests.build/morphless-chunks.script | 7 +-
tests.build/prefix.script | 7 +-
tests.build/prefix.stdout | 8 -
tests.build/rebuild-cached-stratum.script | 9 +-
tests.build/rebuild-cached-stratum.stdout | 22 ---
without-test-modules | 2 +
yarns/architecture.yarn | 16 +-
yarns/implementations.yarn | 16 +-
yarns/morph.shell-lib | 3 +-
43 files changed, 814 insertions(+), 504 deletions(-)
create mode 100644 morphlib/ostree.py
create mode 100644 morphlib/ostreeartifactcache.py
create mode 100755 ostree-repo-server
delete mode 100755 tests.build/build-chunk-writes-log.script
delete mode 100644 tests.build/build-stratum-with-submodules.stdout
delete mode 100644 tests.build/build-system-autotools.stdout
delete mode 100644 tests.build/build-system-cmake.stdout
delete mode 100644 tests.build/build-system-cpan.stdout
delete mode 100644 tests.build/build-system-python-distutils.stdout
delete mode 100644 tests.build/build-system-qmake.stdout
delete mode 100755 tests.build/build-system.script
delete mode 100644 tests.build/build-system.stdout
delete mode 100644 tests.build/morphless-chunks.stdout
delete mode 100644 tests.build/prefix.stdout
delete mode 100644 tests.build/rebuild-cached-stratum.stdout
--
1.7.10.4
8 years, 8 months
Tracking ABI of Baserock build-host systems
by Sam Thursfield
Hello
We have a weakness in the way Baserock systems are bootstrapped, and
today it finally bit me!
Right now Morph ignores the question of whether a chunk built in
'bootstrap' mode will run on other systems. Morph assumes that a chunk
built on an x86_64 Baserock system will function the same on any other
x86_64 Baserock system. So for example, the cache key of stage1-binutils
will be the same on any two Baserock systems, assuming it's the same
architecture, same build instructions and same source code commit.
Anyone who has been in software more than 5 minutes will know this is
fantasy. But it's a very convenient fantasy. I'm not sure how many
people have actually found themselves on the wrong side of this
assumption so far -- it can't be many, or the mailing list would be full
of complaints.
I'll quickly sum up the problem it caused me. On ARM hard-float systems,
the upgrade from EGLIBC 2.15 to GLIBC 2.20 introduced an ABI break:
/lib/ld-linux.so.3 became /lib/ld-linux-armhf.so.3. So dynamically
linked programs built on an ARM hard-float system using EGLIBC 2.15
won't actually run on a GLIBC 2.20 system: they'll give a 'not found'
error. I had an ARM Mason set up to use a shared artifact cache which
was already being used by a much older ARM distbuild network. The older
distbuild had built and uploaded the bootstrap chunks stage1-binutils,
stage1-gcc etc. The new Mason was working fine with these until it had
to rebuild a bootstrap chunk: I think it was stage2-make. At this point
it tried to *run* the tools from stage1-binutils and stage1-gcc to build
make, and they didn't work because they were linked against the wrong
ld.so. Result: a confusing build failure!
I think we can fix this ABI break by creating a compatibility symlink in
/lib, and I'll try doing that. But it highlights a hole in our story of
'everything is reproducible and it won't randomly break for you'. Here
is a list of things we could do to tie that hole closed.
Note when I say "host system" below I'm referring to the Baserock system
that is running `morph build`. Not VM hosts.
1) Include the cache key of the host system in the cache key of each
chunk built in 'bootstrap' mode.
- assumes Morph is running on a Baserock system
- makes cache.baserock.org less useful, because unless you're running
the exact same build-system as the Mason that built the artifacts, your
Morph will come up with different cache keys for the same commit of
definitions and will build everything locally.
2) Include the cache keys of certain chunks from the host system in the
cache key of each chunk built in 'bootstrap' mode.
- assumes Morph is running on a Baserock system, and makes assumptions
about the makeup of that system
- non-trivial to implement
At present the list of chunks would be something like: glibc, binutils,
gcc. The list would have to be maintained by a human in definitions.git,
and we'd have to make a judgement call about where to draw the line.
Once you start digging you realise every component *could* affect how
something is built, so I think going down this road is a bit pointless,
but it might be worthwhile stepping stone while we try to achieve (1).
3) Always build bootstrap chunks locally
- will make getting started slower for everyone (each new user will need
to build GCC twice locally before doing anything else)
4) Statically link bootstrap chunks.
- requires some big changes to the bootstrap, I don't know if it would
actually be possible to statically link everything in stage1 and stage2
- stage1 and stage2 artifacts would be bigger
- still vulnerable to broken versions of GCC/G++/Binutils generating bad
binaries
- will only fix our current example Linux/GNU C/C++/Fortran bootstrap
(the 'build-essential' stratum), will not solve the problem for everyone
(although the principle would remain the same)
5) Make sure we never break our reference bootstrap
- this is our current approach, but it clearly doesn't always work, and
it continually requires developers and reviewers to think whether a
change will might break the bootstrap on any of our platforms
Anyone have any more suggestions for how we could solve this? Any
preferred solutions?
In writing this email I've convinced myself that (1) is really the only
option and so we should make it happen sooner rather than later, on the
assumption that the longer we leave it the more painful it will become.
If the Mason systems are always running latest master of definitions,
then as long as you are also running latest master, you'll be able to
use artifacts from cache.baserock.org. Except if you run a devel-system
instead of a build-system you won't, because it'll have a different
cache key. I have a possible idea for how to fix this if we moved to
allowing arbitrary nesting of components, but I think this email has
gone on a while already, and it's not something that is going to get
done next week.
Please let me know your thoughts! This is a bit of a mindbender so don't
be afraid to ask questions. I know that Emmet has expressed a desire for
(1) multiple times already, but I think it's only been in IRC so I
haven't tried to hunt out previous discussions from the mailing list.
Thanks
Sam
--
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575
8 years, 8 months
[PATCH] Add mips support to morph
by Simon Hoinkis
repo: ssh://git@github.com/mossmaurice/morph.git
branch: baserock/simonhoinkis/mips64
commit: 79bfcdbccdc5d45028b69df720f1f348c65843ed
This patch adds support to morph for MIPS32/64 in big and little endian.
Simon Hoinkis (1):
Change build environment to support MIPS32/64 BE and LE
morphlib/__init__.py | 4 ++--
morphlib/buildenvironment.py | 11 +++++++++++
morphlib/util.py | 4 ++++
3 files changed, 17 insertions(+), 2 deletions(-)
--
1.8.4
8 years, 8 months
[RFC 0/9] Branch morph
by Richard Ipsum
repo: git://git.baserock.org/baserock/baserock/morph
ref: baserock/richardipsum/existential-fix
head: fb3a9ad9475a8c99d266de3c860fcbe7182e8f72
land: master
This series is based on a fix for morph that will change our interpretation
of definitions, because versioned definitions are a very new addition it's
not clear how to proceed with this fix. So this series comes in RFC form
which should hopefully provide a concrete basis for our discussion.
Two approaches to versioned definitions have been discussed in #baserock,
current HEAD of morph master almost implements option 1)
but there's currently no way for code to test what version of definitions
is in use, existing functions for parsing/checking version would need to be
modified to allow this.
Approaches:
1) version 0 == unversioned, older definitions with no version file will
be interpreted as version 0, any changes to morph will maintain backwards
compatibility with version 0 for the time being.
2) Branch morph and introduce version numbers to morph,
there will be two active branches of morph, a 0.x.y branch
and a 1.x.y branch, we may obviously decide on a different versioning
scheme but regardless of versioning scheme there are two branches.
0.x.y will support versions 0,1 and unversioned,
fixes will be supplied for users who still use these older
version of definitions.
1.x.y will support versions 1 and 2 to begin with and will not support
unversioned definitions, this allows us to remove parts of morph that are
no longer needed without having to worry about backwards compatibility with
ancient versions of definitions.
This RFC is intended to be used with option 2, once merged with master it
will make unversioned definitions invalid, so, a 0.1.1 branch of morph
(if we go with that scheme) should be created before this is merged.
If we choose option 1 this series will need to be reworked before
it can be merged.
In addition if we do go with option 2, a patch should be submitted to
the 0.1.1 branch to make it suggest the user upgrade their version of morph
if morph detects the definitions version to be > 1.
Richard Ipsum (9):
Fix: check that path to chunk morph exists
Require definitions to be versioned
Make missing path fix conditional on version
Add missing path warning for defs versions <= 1
Add version 2 to supported versions
Drop support for version 0
Improve error message for missing morph reference
Swap nested ifs for and
Add VERSION file to test repos
morphlib/sourceresolver.py | 75 +++++++++++++++++++++++++++++++++----------
tests.build/setup | 14 ++++++++
tests/show-dependencies.setup | 7 ++++
yarns/implementations.yarn | 4 +++
4 files changed, 83 insertions(+), 17 deletions(-)
--
2.3.0
8 years, 8 months
