July 2015 - baserock-dev - listmaster.pepperfish.net

[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

7
14
0 / 0

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

4
8
0 / 0

Next steps for the Baserock definitions format?

by Sam Thursfield

Hello As you could tell by the continuous patches and emails, over the past few weeks I have been looking into schemas and migrations for the Baserock definitions format. The actual goal was to make it easy to understand and to change the Baserock definitions YAML syntax and the Baserock data model! It took me a good week to do definitions version 6 (and we still can't use it in the reference systems til a release is done) so I can hardly claim that making changes is now easy. I think this is mostly because we still have a dependency tangle between build tools, definitions.git, the definitions format, and the released reference systems. I'm not going to be looking at this further for now, so this mail is a summary on where we are and an open question on where we might go from here. What we have ------------ - A pattern for doing automated forward migrations of existing Baserock definitions (see `migrations/*` in definitions.git[1]). - (Proposed) JSON-Schema descriptions of the Baserock definitions YAML representation format: <https://gerrit.baserock.org/1022/>. - A 'homepage' for the Baserock definitions format: <http://wiki.baserock.org/definitions/>. Actually, the main thing I've wanted to do is separate the concept of the 'data model' from the .morph files that we actually deal with. It's important to represent data in a way that people can read and edit, and it's also important to represent data in a way that computer programs can operate on. These two things are usually at odds, though, and I feel that in the past we've been derailed by trying to optimise for both use cases at once. [1]: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.gi... Where we can go from here...? ----------------------------- We need to do a release of the Baserock reference systems so that we can use definitions format version 6 (and hopefully version 7, if accepted) in our definitions.git repo, and drop support for older versions from Morph and YBD. The description of the definitions format at <http://wiki.baserock.org/definitions/current/> needs bringing up to date. Hopefully a lot of it can be removed and replaced with a link to JSON-Schema and OWL schemas. Beyond that, I have no concrete plans. But here are some ideas... Morph's validation code could be replaced with the Python 'jsonschema' module, although so far I've not been overly happy with the error messages that module gives, so far. I would like to see how simple a Baserock build tool can be. YBD is interesting, but now that there is no need to do build-system autodetection (as of definitions format version 6) I think you could write a 'definitions repo -> massive shell script full of build instructions' tool in a couple of hundred lines. It should also now be simple(ish) to convert Baserock definitions to other languages such as Bitbake recipes, Makefiles, the Nix package language, or anything else interesting. We must fix the dependency tangle between Morph/YBD/distbuild, the Baserock reference systems, the definitions format, and the Baserock reference system definitions. This is key to making it actually easy to change the Baserock definitions format. The best way to do it is... left as an exercise. Define a better data model. I came up with an initial one in `baserock.owl` as part of <https://gerrit.baserock.org/1022/>, but I don't think the terms 'Chunk', 'Stratum', 'System' or 'Cluster' are really much use there. Our tools deal with 'something that has build instructions and/or contents', largely. We need to find a name for that concept (or extend an existing concept such as 'Package' from SPDX), and make a more simple and flexible data model. YBD's internal data model has gone some way in this direction already. Once we have a better data model we can update the YAML serialisation format to match. We could try to change both things in parallel, but I think that would be much more difficult. Conditionals! I have some thoughts on how these could be done, which won't fit in this email. The key idea is that conditionals should exist at the level of the YAML representation format. In the abstract, all the possible variants of a system do actually exist, and we need to keep track of which ones are built and which ones are tested. Write a Git merge tool that understands the Baserock definitions YAML representation format. That would make merge conflicts in definitions repos much nicer to deal with, I think. One thing we are still missing is a good name for the "Baserock data model" and especially the "Baserock definitions YAML representation format" :) Sam -- Sam Thursfield, Codethink Ltd. Office telephone: +44 161 236 5575

7 years, 9 months

2
1
0 / 0

Do morph/sandboxlib really need the mount binds stuff?

by Paul Sherwood

Hi I've been using the lovely sandboxlib in ybd for a few weeks now [1] - it basically re-implements morph's sandboxing in a generic way, using linux-user-chroot where it can, but falling back to chroot if l-u-c is not available. As far as I can tell, I still get working results whenever it takes the chroot path, but I won't be sure until we get to bit-for-bit. Anyway, while trying to make it possible to parallelise ybd, I noticed that the l-u-c path can run into trouble if there are other things creating/deleting directories while sandboxlib is doing its magic. If something removes any of the directories it sets out to bind (and for my use-case that includes lots of tmp directories) then 'mount (MS_BIND): No such file or directory' occurs. I assume the same issue would occur for multiple instances of morph, or if something was adding/deleting directories during a morph run, but I haven't tried it. I don't think this problem happens using the sandboxlib chroot path, which makes me wonder a) what are the downsides/risks in not doing the binds? b) does anyone have any ideas to deal with the corner-case I've described above? FWIW I've created an issue at [2] br Paul [1] https://github.com/CodethinkLabs/sandboxlib [2] https://github.com/CodethinkLabs/sandboxlib/issues/9

7 years, 10 months

3
6
0 / 0

Thoughts on artefact splitting in ybd

by Paul Martin

This follows a quick bit of brainstorming with Sam Thursfield. -=- # `ybd` artefact splitting ## Current situation The way `ybd` currently creates artefacts is much simplified compared with `morph`. It builds and includes everything "installed" by that component into a single artefact. ## How `morph` does it `morph` has a list of default rules, currently hard coded into its source, which defines a set of regular expressions which allocate files to each generated artefact on a first-found basis. Individual definitions may override this by using an `artifacts` list. It is also possible in a system definition to select individual artefacts by providing an `artifacts` table within each `strata` table. There are plans in `morph` to move the default artefact rules out into a file within the definitions tree. ## How `ybd` might do it `assembly.assemble()` currently invokes the _artifact creation_ phase by running `cache.cache()`, and creates monolithic artefacts as compressed tarballs. The compression phase currently used in artefact generation is expensive. This is probably not needed for local storage, and time is wasted in compressing the artefacts and then uncompressing them into individual files for the "unpacked" tree. I suggest a change to `ybd` to allow for artefact splitting by modifing the metadata associated with an artefact. There is currently a list of files contained in that artefact within the metadata. I propose partitioning that into a list of split tags, each containing a list of the files within that split. For example, where an artefact's metadata might currently contain: repo: upstream:zlib ref: db333af7e9b90a23fd7f9cd8dc128123b34bf698 . ./usr ./usr/share ./usr/share/man ./usr/share/man/man3 ./usr/share/man/man3/zlib.3 ./usr/lib ./usr/lib/libz.a ./usr/lib/libz.so ./usr/lib/libz.so.1 ./usr/lib/libz.so.1.2.8 ./usr/lib/pkgconfig ./usr/lib/pkgconfig/zlib.pc ./usr/lib/debug ./usr/lib/debug/libz.so.1.2.8 ./usr/include ./usr/include/zconf.h ./usr/include/zlib.h ./baserock ./baserock/zlib.meta it might instead contain: repo: upstream:zlib ref: db333af7e9b90a23fd7f9cd8dc128123b34bf698 artifacts: - ".": - . - ./usr - ./baserock - ./baserock/zlib.meta - doc: - ./usr/share - ./usr/share/man - ./usr/share/man/man3 - ./usr/share/man/man3/zlib.3 - libs: - ./usr/lib - ./usr/lib/libz.so - ./usr/lib/libz.so.1 - ./usr/lib/libz.so.1.2.8 - devel: - ./usr/lib - ./usr/lib/libz.a - ./usr/lib/pkgconfig - ./usr/lib/pkgconfig/zlib.pc - ./usr/include - ./usr/include/zconf.h - ./usr/include/zlib.h - debug: - ./usr/lib - ./usr/lib/debug - ./usr/lib/debug/libz.so.1.2.8 Rather than holding a fully unpacked representation of the artefact within the ybd cache, the metadata `artifact` table can be used to control which files `tar` extracts. The unpack stage in the sandbox module would then select the table(s) of filenames to unpack and use that with the `-T` option to `tar`, to restrict the extraction process to just those filenames. If it is still desired to keep an unpacked representation within the `ybd` cache directory, the same metadata tables can be used to control which files are copied into the sandbox. However, extraction from an uncompressed tarball might be more space-efficient. The benefits of this scheme are: * Minimal changes to current code. * `ybd` continues to generate a single cache object for each artefact. Disadvantages are: * Cache files will remain incompatible with `morph`. -- Paul Martin http://www.codethink.co.uk/ Senior Software Developer, Codethink Ltd.

7 years, 10 months

2
1
0 / 0

Proposal for Baserock definitions format version 6

by Sam Thursfield

Hello I'd like to propose a change to the Baserock definitions format. Which would bring us to version 6. The change is: require specifying build instructions for every chunk in definitions.git. Wait! Put the fiery pitchfork down for a moment. This just means adding an extra field to stratum .morph files, so you have to specify 'build-system' alongside 'repo' and 'ref' for any chunks that don't have their own .morph file. It doesn't mean we now need to write .morph files for all 763 chunks in definitions.git. The reason for this change is: I'd like to make it easy to go from a definitions.git repo full of .yaml files, to a full set of build instructions. Currently you can't do that -- for every chunk that doesn't specify build instructions, you need to know the list of files in the given commit being built. Which, in practice, means you need an internet connection, or a local cache of all the chunk repos which is up to date with your definitions. I think that's too much to ask of people who just want to find out how to build something. I realise that if you want to actually run the build, you need the repos available at some point anyway. But you may just want to analyse definitions or convert them to a different format, and it's pretty lame to require an internet connection or a huge local Git cache just for that. I propose that we remove the ability to store chunk .morph files in chunk repos, for the same reason. I don't think anybody has been using this feature for years. - Migration script for definitions v6: https://gerrit.baserock.org/1002/ - Example of migrated definitions: https://gerrit.baserock.org/1003/ - Morph patch to add support for definitions v6: https://gerrit.baserock.org/1004/ - YBD patch to build definitions v6: https://github.com/ssssam/ybd/tree/sam/definitions-version-6 - Example Morph patch to remove support for definitions v3-v5: https://gerrit.baserock.org/1001 Please let me know your thoughts! In the form of a +1 or -1 perhaps. I think it's best if we keep discussion of the overall approach on the mailing list, rather than in Gerrit. I've posted patches to illustrate the proposal, but I don't want them to be merged unless the readers of this list are happy with the change to the definitions format. If this change is approved, I'll look at moving the predefined split rules and build commands into definitions.git, at which point it'll be possible to actually get a full set of build instructions just by analysing definitions.git. Thanks! Sam -- Sam Thursfield, Codethink Ltd. Office telephone: +44 161 236 5575

7 years, 10 months

3
6
0 / 0

[RFC] CIAT Continuous Integration and Automated Test

by Paul Sherwood

Hi folks as part of what I'm doing in GENIVI and AGL, I've undertaken to prepare a Statement of Work for public-facing continuous integration and automated test infrastructure. I've taken the liberty of starting a draft of this on the Baserock Wiki at [1] because ikiwiki is my weapon of choice in the wiki wars so far, and I am aware this topic is of interest to various Baserock constituents. Also, I know that we've experimented with various approaches and had success with some of the relevant technologies for Baserock itself. My hope is to get the implementation moving quickly, using available FOSS solutions as far as possible, and therefore I'll be happy to recommend Baserock tooling (eg Trove) if it clearly makes sense and can fit with established technology choices (eg Bitbake for builds). I'd very much appreciate feedback and comments here before I submit a second draft for consideration elsewhere. The text is below. I'll be happy to incorporate any comments received by reply here on the list or as private email. br Paul SoW: Continuous Integration and Automated Test ===================================== Background -------------- Various open source 'umbrella' projects including GENIVI, AGL and PRPL have a need to establish and maintain public-facing infrastructure for Continuous Integration and Automated Testing of their software architectures. This aims to document generalised requirements for CIAT in a 'Statement of Work' form, so that actual implementations can be planned and delivered. It is hoped that a workable solution can be found which satisfies requirements for all of these organisations, but it is expected that each may have further specific requirements, and may for its own reasons choose alternative approaches for some or all of the parts of this infrastructure to satisfy organisation-specific goals. The content here is offered to all of the mentioned organisations (and more widely) for consideration. It is recognised that maintaining a CIAT infrastructure can be of significant engineering value, but involves ongoing work and cost. Therefore collaboration on a generally useful approach can offer particular benefits both in terms reduced cost per project, and increased quality through (for example) cross-validation and re-use of tests. Scope -------- CIAT includes * collection of source code from upstreams including new versions as required on an ongoing basis * recipes and/or automated instructions for building the upstream components * recipes and/or automated instructions for installing the upstream components into an integrated 'distro' * Continuous Integration tooling which executes the recipes/instructions automatically, either * on user demand, or * triggered by changes to the instructions or components themselves * publication of the built/integrated artefacts which are output by the execution of the ci tooling * Automated Test tooling which executes sets of tests on deployed instances of the integrated software * publication of the results of the automated tests * demonstration of license compliance * machanism for formal code review prior to merging of changes, either * before build and test or * after build and test as candidate (preferred) Requirements ---------------- * all of the CIAT software tooling must be FOSS * any custom work to make the solution fit specific use-cases for GENIVI, AGL, PRPL must be FOSS * where possible the solution should align with the upstream developers for its components. * instructions for creation and setup of a working instance of CIAT infrastructure must be provided * minimal manual maintenance - the system should be mostly automated: * minimal effort for license compliance (eg scripted license checking, publish applicable source for all artefacts) * developer/integrator engineers can trigger build/test using git push. * CIAT must support * several automated test frameworks (eg fitnesse, phoronix, LTSI Test Project) * testing scenarios on multiple architectures (eg ARMv7, x86_64) for both virtual machines (eg QEMU) and actual hardware [1] http://wiki.baserock.org/ciat/

7 years, 10 months

2
2
0 / 0

[RFC] New 'gang' approach for parallelising build and integration tasks

by Paul Sherwood

Background ========== There's been a lot of work done in the Baserock project (and many, many other projects!) around how best to take advantage of build machines with many cores, and/or setups with multiple build-servers (eg distributed team, build farm, cloud). Baserock's distbuild functionality has been developed and redeveloped to work on multiple architectures, and there have been several implementations of mason (continuous integration), and some exploratory implementations of firehose (automated integration). Broadly our requirement is to split large jobs into parallelizable component tasks, and spread them across available systems, processors and/or cores. Then we integrate the results as artifacts, and publish them. We want to be able to initiate jobs as users, alongside automatically-generated jobs triggered by changes from upstreams. We want the solution to work reliably on several processor architectures, both big-endian and little-endian. We want to output the built artifacts automatically. And we want to minimise wall clock time waiting for builds. Current Approach ================ For users working on a single machine, we have: - a commandline tool (morph, ybd) to work out the build order and run the component tasks - a local cache of artifacts made by the tool, or downloaded from a server of published pre-built artifacts For users with access to a build farm (distbuild): - a scheduler/controller to break up the jobs and farm out the individual tasks - build workers to do the tasks (running on a range of architectures), using the command line tool (morph only) - local cache of built/downloaded artifacts for each worker - shared cache for uploaded/published artifacts For continuous integration (mason): - a server which initiates jobs on a distbuild network and presents the results/status via the web For automated integration (firehose): - a server which monitors a set of git repos on another server, and triggers jobs for distbuild algorithmically New theory ========== Some months ago it occurred to me that it might be possible to simplify the distbuild approach, and also improve the mason/firehose approach, by just having a gang of workers and throwing all the jobs at all of them. I know this seems ridiculous - all the workers will attempt all the work, constantly racing against each other. But what if each worker randomises its task order, and they all share an artifact cache? There will still be some races, but once a task is completed later workers will find the artifact, so no need to re-do the work. So in theory the overall wall-clock time for a gang of workers could be less than for one worker. But our workloads are complex: - some tasks can be parallelised (eg build-commands for some components) - some can not (eg configure-commands, or creation of build-essential) - sometimes jobs will mostly rely on existing cached artifacts (eg just rebuilding python projects) - some require rebuild of pretty much everything (eg change to GCC or glibc). As a result it was not obvious whether the proposed simplification would actually work in reality, without testing an actual implementation. Practice ======== A couple of weeks ago I got around to making ybd parallelizable, with atomic updates to artifact cache, and non-clashing sandbox areas. This weekend I've had a chance to test it on some realistic scenarios. I've been using an AWS machine with 40 cores, 160GB memory (2.4 GHz Intel Xeon® E5-2676 v3 Haswell) ($2.50 per hour). I've also tested to get comparable times for my MacBookPro. The results seem quite promising: Scenario 1: ----------- Target is build-system-x86_64. No pre-built artifacts are present in the cache: - MacBookPro, instances = 1, max-jobs = 6: [TOTAL] Elapsed time 02:39:04 [1] - AWS m4.10xlarge, instances = 1, max-jobs = 60: [TOTAL] Elapsed time 01:26:37 [2] - AWS m4.10xlarge, instances = 6, max-jobs = 10: [TOTAL] Elapsed time 01:04:29 [3] So the gang achieved a timesaving of 25%, which seems worth having. Note that some of the longest tasks in this scenario don't parallelise since everything needs build-essential. Scenario 2: ----------- Target is build-system-x86_64. Artifacts for base-system-x86_64-generic already exist in the cache: - MacBookPro, instances = 1, max-jobs = 6: [TOTAL] Elapsed time 00:45:25 [4] - AWS m4.10xlarge, instances = 1, max-jobs = 60: [TOTAL] Elapsed time 00:19:33 [5] - AWS m4.10xlarge, instances = 6, max-jobs = 10: [TOTAL] Elapsed time 00:08:36 [6] Actually the final artifact was completed by instance 5 at 00:07:08, but the rest of the instances took a long time to notice. So the gang delivered the result in 36% of the time, a saving of 64%. Much more of this work has been done in parallel. Scenario 3: ----------- Target is all the x86_64 systems in ci.morph. No pre-built artifacts are present in the cache: - MacBookPro, instances = 1, max-jobs = 6: [TOTAL] Elapsed time 07:13:37 [7] - AWS m4.10xlarge, instances = 1, max-jobs = 60: [TOTAL] Elapsed time 02:53:51 [8] - AWS m4.10xlarge, instances = 6, max-jobs = 10: [TOTAL] Elapsed time 01:46:54 [9] Incidentally my first attempt at the single instance crashed on gstreamer, after 535 tasks of the allotted 652 (no idea why). I've seen some other occasional fails over the last few weeks, and this highlights that the gang approach is more robust against hard-to-reprodue errors - if one worker fails, it doesn't stop the whole job. Next steps ========== There's still work to do, for example: - 6 instances, 10 max-jobs was chosen on a hunch, but it may be worth trying various combinations to plot the result and work out the sweet spot. Also this will likely be system-specific, varying based on available memory, io bandwidth, cores and clock speed. - ybd doesn't have a reliable/scaleable cache-server and upload mechanism yet, so i've not tried true distributed building. - not sure how this could best work for multi-arch distbuild use-cases - currently ybd just skips anything that doesn't match its host architecture. - there's clearly room for optimisation (eg kill the gang once the artifact is delivered) br Paul Note ybd logs have lots of information in them, but the styling may be obscure at first - for example: - outputs from all gang workers are mixed together as they happen - the instructions the workers run are mixed in too - and so is the tail from the log of any crashed instruction - for the gangs, first digit alone at the start of the line denotes which worker is logging. - all situations where a race occurred are logged with the word 'Bah!' in them, so easy to grep - all timings are logged with the word 'Elapsed' in them - the counter shows [artifacts done/artifacts to do/total artifacts] - for a gang, no individual worker instance will reach the 'artifacts to do' total [1] http://sprunge.us/PhQS [2] http://sprunge.us/HYGf [3] http://sprunge.us/MjQX [4] http://sprunge.us/HVIV [5] http://sprunge.us/FPfJ [6] http://sprunge.us/RGgH [7] http://sprunge.us/UAZa [8] http://sprunge.us/bWea [9] http://sprunge.us/THBA

7 years, 10 months

2
2
0 / 0

confgit is not updated.

by Ravindran, Madhusudhanan (M.)

Hi, Can you help figure the issue here journalctl reports: Jul 15 15:01:59 vtsc-trove gitano[4753]: 4753.150159: Client connected from unknown ip as lorry () Executing command: git-upload-pack '/vtsc-trove/local-config/lorries' Jul 15 15:01:59 vtsc-trove lighttpd[465]: 2015-07-15 15:01:59: (mod_fastcgi.c.2673) FastCGI-stderr: File "/usr/lib/python2.7/site-packages/lorrycontroller/readconf.py", line 47, in run Jul 15 15:01:59 vtsc-trove lighttpd[465]: 2015-07-15 15:01:59: (mod_fastcgi.c.2673) FastCGI-stderr: File "/usr/lib/python2.7/site-packages/lorrycontroller/readconf.py", line 104, in get_confgit Jul 15 15:01:59 vtsc-trove lighttpd[465]: 2015-07-15 15:01:59: (mod_fastcgi.c.2673) FastCGI-stderr: File "/usr/lib/python2.7/site-packages/lorrycontroller/readconf.py", line 128, in update_confgit My issue is /home/lorry/confgit/lorry-controller.conf never gets updated and retains older configuration, where as /home/git/repos/vtsc-trove/local-config/lorries.git has updated commits with configuration changes. Regards, Madhu

7 years, 10 months

2
3
0 / 0

Generic Cache Server

by Lauren Perry

I've recently been working on an adaptation to the morph-cache-server that would allow it use outside of morph. This has involved a removal of cliapp and the repository caching functions to offer more general use cases (at the moment the idea is for it to be both morph and YBD compatible). Details of this can be found here [1] Given that this will still be able to utilise morph, is this something that Baserock would be interested in? And if so, would there be value in hosting on G.B.O. once the functionality to use multiple build methods has been implemented, or would this be better hosted in an external location (i.e. Github)? Regards, Lauren [1] http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015...

7 years, 10 months

4
13
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

baserock-dev July 2015