| *** tristan has quit IRC | 05:46 | |
| *** tristan has joined #buildstream | 06:00 | |
| *** ChanServ sets mode: +o tristan | 06:00 | |
| *** jonathanmaw has joined #buildstream | 08:45 | |
| jonathanmaw | morning tristan, looks like my overnight/weekend build failed, while building gnome-system-image.bst, due to running out of disk space | 08:46 |
|---|---|---|
| tristan | Aha ! | 08:46 |
| tristan | Yeah that'll happen especially at that stage :-/ | 08:46 |
| tristan | What could really be handy, is a `dd` tool which handles sparse files well | 08:47 |
| jonathanmaw | tristan: yep, my brother's lamented its absence many times. | 08:47 |
| tristan | that image splicing will balloon your disk space because it will create the filesys images separately and then create a huge partitioned image to fit it inside, and then splice those images into one big one | 08:48 |
| tristan | yeah | 08:48 |
| jonathanmaw | so I'm going to need more than 4G free space | 08:48 |
| tristan | jonathanmaw, still, it's good news that that's the only reason it failed :D | 08:48 |
| tristan | yocto has sparse copy which requires python http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/filemap.py#n533 | 08:50 |
| tristan | I suppose something like that can be used | 08:51 |
| tristan | jonathanmaw, also, if you have failed builds, they will not be automatically purged by BuildStream | 08:52 |
| tristan | take a look at ~/.cache/buildstream/build | 08:52 |
| tristan | anything in there is delete worthy | 08:52 |
| *** ssam2 has joined #buildstream | 09:01 | |
| jonathanmaw | tristan: I'm building with 13G free space, and I get a backtrace https://pastebin.com/bAiiF3Qx | 09:06 |
| jonathanmaw | though the build seems to continue trying | 09:07 |
| jonathanmaw | it's managed to use all my disk space, so it looks like it's not handling running out of disk space gracefully, rather than failing for other reasons, though. | 09:07 |
| jonathanmaw | tristan: I think there's places that store temporary files other than build | 09:14 |
| jonathanmaw | since I had 13G before, and after a couple of failed builds, I have 8.2G after wiping .cache/buildstream/build | 09:14 |
| tristan | Hmmm | 09:18 |
| tristan | jonathanmaw, do you have today's master ? | 09:19 |
| jonathanmaw | no | 09:19 |
| jonathanmaw | pulling now | 09:19 |
| tristan | that should help with the stack traces, although it looks like perhaps the _ostree.py commit() code is failing to catch an exception | 09:20 |
| tristan | lets see if master fixes it, because that second part of the trace should be handled now, fixed over the weekend | 09:20 |
| jonathanmaw | \o/ build succeeded | 09:33 |
| tristan | Yay ! | 09:33 |
| jonathanmaw | after I found 50G to clear, so I don't think I can confirm that the ugly stack trace problem was solved | 09:33 |
| tristan | Alright, I did clean up some stack traces in the frontend over the weekend so I hope it's gone | 09:34 |
| tristan | if not, we'll fix it later | 09:34 |
| jonathanmaw | I'm sure I'll run out of disk space again | 09:34 |
| tristan | hah | 09:36 |
| tristan | jonathanmaw, Ok so... tarball source ! | 09:37 |
| tristan | :D | 09:37 |
| tristan | Have you had time to take a look at how the Source object works and what there is to implement ? | 09:37 |
| jonathanmaw | not yet | 09:38 |
| jonathanmaw | currently in a meeting for another project, so I can get started in an hour at the latest | 09:38 |
| tristan | Sure, I may be stepping out for lunch/dinner soon | 09:39 |
| tristan | but I'd like to run down the functionality of how the sources work with you so that it's well understood | 09:39 |
| jonathanmaw | \o/ got GNOME graphical interface running in qemu. too slow to run, unfortunately, I should look at setting it up with virt-manager. | 09:56 |
| tristan | jonathanmaw, yeah I use virtualbox normally | 09:56 |
| * tristan has a script that takes the image and generates a .vdi | 09:56 | |
| tristan | jonathanmaw, here: https://pastebin.com/MW3WBpV7 | 09:58 |
| tristan | may be helpful, but you may have your own VM wizardry at your disposal :D | 09:58 |
| *** tristan has quit IRC | 10:03 | |
| ironfoot | paulsher1ood: thanks for the reviews. I though python 3.5 was needed | 10:13 |
| ironfoot | jonathanmaw: do you know the answer to that? ^ | 10:14 |
| ironfoot | best one to ask is tristan, will wait for him :) | 10:14 |
| jonathanmaw | I managed to build using python 3.4.2 | 10:16 |
| jonathanmaw | the only problem that occurred was a circular include loop, that tristan fixed. | 10:17 |
| paulsher1ood | ironfoot: from soon-to-bepublished blog post 'BuildStream now requires python 3.4 instead of 3.5, so this should hopefully be repeatable on most stable distros, e.g. debian jessie ships 3.4' | 10:17 |
| jonathanmaw | I think you still need to add jessie-backports to get ostree, but I don't think I've had to rely on anything built from source. | 10:18 |
| ironfoot | gah, I'm late :) | 10:21 |
| ironfoot | although some people migh like to use this inside of docker, idk | 10:21 |
| ironfoot | might* | 10:22 |
| paulsher1ood | ironfoot: i want to try inside docker, and also vagrant | 10:23 |
| jjardon[m] | ironfoot: we will definitely use it in docker, but in a server, not locally | 11:00 |
| ironfoot | I've read a bit about gitlab registry. That might be useful for using it in a server | 11:01 |
| ironfoot | gitlab CI will update the docker image in the registry, and server would use the latest version available. | 11:05 |
| ironfoot | gitlab CI job to update docker image could run only in tags (releases) | 11:05 |
| *** albfan[m] has joined #buildstream | 11:23 | |
| albfan[m] | Hi there | 11:23 |
| albfan[m] | I think is worth to mention this https://wiki.gnome.org/Initiatives/ContinuousIntegrationForApps | 11:24 |
| albfan[m] | we want to bypass jhbuild, and flatpak is not ready for our purposes, can buildstream be used inside jenkins in some way? | 11:25 |
| ssam2 | hi albfan! | 11:25 |
| ssam2 | buildstream can be used from Jenkins like any other build tool, but depends what your needs are | 11:26 |
| ssam2 | is the plan to build the apps themselves using BuildStream ? | 11:26 |
| ssam2 | if so, the goal is to get feature parity with flatpak-builder, but i don't think things are quite there yet | 11:26 |
| ssam2 | I think it's the next goal though ? | 11:26 |
| albfan[m] | Roughly reuse a flatpak runtime to build app on top of it and run test suite (to collect test reports) | 11:31 |
| albfan[m] | avoiding dependency build hell | 11:31 |
| ssam2 | definitely sounds like something BuildStream could do. tristan is the main guy to speak with, he's not here right now though | 11:32 |
| albfan[m] | At this time, we are waiting for docker+jhbuild to end gnome-todo and deps compilation to see results of a dummy test suite | 11:32 |
| albfan[m] | madness | 11:32 |
| albfan[m] | ssam2: great, if you see the links all is hosted in github by now, so any change can be done by PR or code review there | 11:33 |
| albfan[m] | https://github.com/waltervargas/gnome-todo/blob/master/Dockerfile#L6 | 11:34 |
| albfan[m] | https://github.com/waltervargas/gnome-todo/blob/master/Jenkinsfile#L14 | 11:34 |
| ssam2 | right | 11:34 |
| ssam2 | to be honest, Docker probably isn't needed if you use BuildStream | 11:34 |
| ssam2 | because BuildStream creates its own container to run the build | 11:34 |
| ssam2 | so the host system is totally separate | 11:35 |
| albfan[m] | we have gnome-todo on top of debian, but can be fedora if you want or ubuntu | 11:35 |
| ssam2 | it does require Python 3.4 and OSTree on the host though | 11:35 |
| albfan[m] | better of | 11:35 |
| ssam2 | we have folk running it on Debian Jessie, using OSTree and Bubblewrap from jessie-backports | 11:35 |
| albfan[m] | Here is our jenkins https://github.com/waltervargas/gnome-jenkins | 11:36 |
| ssam2 | https://gitlab.com/BuildStream/buildstream-tests/tree/master is an example of building GEdit on top of the GNOME Flatpak SDK | 11:36 |
| albfan[m] | I have been looking at that. Great I will give it a try | 11:37 |
| * albfan[m] sent a long message: albfan[m]_2017-04-10_11:40:13.txt - https://matrix.org/_matrix/media/v1/download/matrix.org/KxrUxGMtooaTutGuOtjOzgpA | 11:40 | |
| ssam2 | I think demo from https://blogs.gnome.org/tvb/2017/02/06/introducing-buildstream-2/ will be pretty close to what you need | 11:41 |
| ssam2 | `build-stream build gedit.bst` runs the build | 11:41 |
| ssam2 | takes a long time the first time because it has to pull the whole GNOME SDK to a local OSTree repo | 11:41 |
| ssam2 | but if that OSTree repo is shared between builds then subsequent builds should go quick | 11:42 |
| ssam2 | not sure about how `make check` would work off-hand | 11:44 |
| ssam2 | I imagine it's something we want to support | 11:44 |
| ssam2 | but it's a slightly strange case because in most cases the test suite expects to be run from the build tree | 11:44 |
| ssam2 | i think we'll need to wait til tristan returns to figure that out | 11:46 |
| ssam2 | in the meantime, just testing that the app executes is useful | 11:46 |
| ssam2 | hmm, actually no I think this is already supported | 11:46 |
| ssam2 | `build-stream shell --scope build` seems like it might make the build tree available.. | 11:47 |
| ssam2 | that might just make the build-dependencies available rather than the actual build tree | 11:47 |
| *** tristan has joined #buildstream | 11:50 | |
| albfan[m] | about that no problem. We can go to installed tests https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests and execute them with https://git.gnome.org/browse/gnome-desktop-testing | 11:51 |
| ssam2 | ah, that's good news | 11:51 |
| ssam2 | tristan, albfan[m] is looking at implementing https://wiki.gnome.org/Initiatives/ContinuousIntegrationForApps using BuildStream to build the GNOME apps against the Flatpak SDK | 11:52 |
| albfan[m] | but cool to hear something about expose build tree anyway. This week will be really interesting | 11:52 |
| * tristan reads backlog in the logger | 12:00 | |
| tristan | hi albfan[m] :) | 12:01 |
| albfan[m] | Hi tristan, nice blog entry indeed! | 12:01 |
| albfan[m] | can wait to try it. afk now | 12:01 |
| tristan | albfan[m], new blog just hit the streets minutes ago btw :) | 12:03 |
| tristan | https://blogs.gnome.org/tvb/2017/04/10/buildstream-progress-and-booting-images/ | 12:03 |
| tristan | albfan[m], ok anyway will hope to discuss soon any help I can provide :) | 12:04 |
| tristan | from our perspective, buildstream provides a pipeline for running abstract plugins which perform mutations on filesystem data | 12:05 |
| tristan | However, it's quite possible to write plugins which simply make an assertion that installed-tests pass | 12:05 |
| tristan | as usual, there are many ways to skin cats :) | 12:05 |
| albfan[m] | Great, we are looking for something that just work (although awnful) I will make some tries and see how far I get. Then I will ask how to proceed | 12:10 |
| albfan[m] | plugins, plugins, plugins... everything is just a plugin away! | 12:11 |
| *** juergbi has quit IRC | 12:15 | |
| *** juergbi has joined #buildstream | 12:16 | |
| paulsher1ood | tristan: s/into a single artifact, that with some additional/into a single artifact, with some additional/ | 12:30 |
| jonathanmaw | tristan: is there a "tar" output format like there's an sda.img? | 12:38 |
| jonathanmaw | or do I understand correctly that if I just want to look at the output, I can use bst checkout to look at the contents of the stack? | 12:39 |
| tristan | jonathanmaw, I added checkout in a sort of hurry, it may need some changes; checkout will not stage dependencies | 12:40 |
| tristan | jonathanmaw, however if you want for a quick check, use `bst shell` | 12:40 |
| tristan | bst shell --deps runtime foo.bst | 12:41 |
| tristan | for a stack | 12:41 |
| jonathanmaw | and that'll dump me into a shell inside that stack? cool! | 12:41 |
| tristan | jonathanmaw, yep :) | 12:42 |
| tristan | it'll wipe the directory clean though once you exit the shell | 12:43 |
| jonathanmaw | I take it I can do `bst build <stack>` too? | 12:43 |
| tristan | yes | 12:43 |
| jonathanmaw | right, that gives me a path to testing how tar sources are working. | 12:43 |
| tristan | jonathanmaw, ideally, we should have regression tests for that... see the tests/sources directory | 12:44 |
| tristan | we've (I've) been falling behind on test coverage, though :'( | 12:45 |
| jonathanmaw | aha | 12:45 |
| tristan | Some of it just cannot be tested easily | 12:45 |
| tristan | And some of it just doesnt fall into the context of a `make check` like semantic (i.e. I dont want `./setup.py test` to require downloading external resources) | 12:46 |
| tristan | jonathanmaw, Ok so just for a rundown; there is configure(), preflight(), fetch(), track() and stage() basically to implement | 12:47 |
| tristan | alot of this (I hope) is quite obvious, what they should be doing | 12:47 |
| tristan | Oh, since recently I also added another | 12:47 |
| tristan | (not that recently actually) | 12:47 |
| tristan | right, set_ref() and get_ref() | 12:48 |
| jonathanmaw | tristan: Basically every method that source.py raises an ImplError in? | 12:48 |
| tristan | and get_consistency() | 12:49 |
| tristan | Yeah :) | 12:49 |
| tristan | jonathanmaw, for tarballs, we will want track() to resolve the sha256sum of the tarball and return that | 12:49 |
| tristan | So that users need not spend time with copy/paste of checksums | 12:50 |
| tristan | Eventually, we may want something more fancy for that, but for starters, that will be good | 12:50 |
| jonathanmaw | ok | 12:52 |
| jonathanmaw | looking at plugin.py, do I also need to implement get_unique_key()? | 12:52 |
| tristan | jonathanmaw, yes :) | 12:53 |
| tristan | That is the basis for cache key calculation of a Source | 12:53 |
| tristan | jonathanmaw, see how git.py does it | 12:53 |
| jjardon[m] | Hi, Im trying to use bst to build definitions but Im getting a quite strange error when trying to build the converted gnome system: https://gitlab.com/baserock/definitions/builds/14040020 (that file is actually there): any idea? | 12:54 |
| tristan | jonathanmaw, note that for a source, we want to use the *unresolved* uri (not resolved by any alias) | 12:54 |
| tristan | jonathanmaw, i.e. this means you can start mirroring your sources in one location and it wont cause all cache keys to change | 12:54 |
| tristan | jjardon[m], is that a re-converted thing, following the defs2bst migration path docs ? | 12:55 |
| tristan | or a naked build of 'build-gnome' branch in buildstream-tests directly ? | 12:55 |
| tristan | jonathanmaw, to understand the power of track, try: bst track foundation/systemd.bst (for example) | 12:56 |
| tristan | jonathanmaw, and then do 'git diff -a' in the buildstream-tests repo (assuming you have the build-gnome branch checked out) | 12:56 |
| tristan | it's still a little rough around the edges (we need to convert errors to warnings in there in case of bad branches) | 12:57 |
| tristan | it also follows the same semantics with a --deps argument (by default now, track will only track one element, unless --deps is specified) | 12:58 |
| jjardon[m] | tristan: converted | 12:58 |
| tristan | jjardon[m], Ok, did you reuse the same project.conf ? | 12:59 |
| jjardon[m] | Its only doing this atm: https://gitlab.com/baserock/definitions/blob/jjardon/bst2/.gitlab-ci.yml#L19 | 12:59 |
| tristan | Ah, Ok I think I need to pull that change into the gnu-toolchain branch | 12:59 |
| tristan | jjardon[m], Ok I see, I know why it's happening, I think... hold on... | 13:00 |
| tristan | oh that's strange | 13:00 |
| tristan | jjardon[m], ok so, first of all, you are calling `bst build elements/gnome/gnome-system-x86_64-content.bst` | 13:02 |
| tristan | which is intuitive, and I've actually been thinking of supporting | 13:02 |
| tristan | but is currently not supported | 13:03 |
| tristan | jjardon[m], what you want is in fact bst build gnome/gnome-system-x86_64-content.bst | 13:03 |
| tristan | jjardon[m], because I added in project.conf, an option to say "all the elements go into a <subdir>" | 13:03 |
| tristan | every element is referred to, relative to the elements directory | 13:03 |
| tristan | in the gnu-runtime project.conf there, it's 'elements' | 13:04 |
| tristan | I also dont think that the file `/builds/baserock/definitions/buildstream-tests/./bluetooth.bst` should exist | 13:05 |
| tristan | because you ran defs2bst.py with --output into the elements/ subdir (which is what you want anyway) | 13:05 |
| tristan | Although, I'm confused as to why it got that far at all | 13:05 |
| tristan | it should have failed before that | 13:05 |
| tristan | jjardon[m], Also one thing I'm not 100% sure of, it may very well be that you need to run defs2bst more than once | 13:06 |
| tristan | jjardon[m], i.e. once on the system morph, and once more on say (for that system), gnome/strata/gnome.morph | 13:06 |
| tristan | jjardon[m], this depends on how ybd generates the <target>.yml we use | 13:07 |
| tristan | I am guessing here, that someone forgot to include bluetooth in the system.morph for the gnome system ? | 13:07 |
| jjardon[m] | maybe, let me check | 13:09 |
| tristan | nope | 13:09 |
| tristan | I just checked, it's there | 13:09 |
| tristan | jjardon[m], first try removing the leading `elements/` on your command line | 13:09 |
| tristan | of bst build | 13:09 |
| tristan | Also note that cd is not really necessary | 13:10 |
| tristan | You can do: bst -C buildstream-test build gnome/gnome-system-x86_64-content.bst | 13:10 |
| tristan | jjardon[m], note that indeed, in your 'find' output: buildstream-tests/elements/bluetooth.bst | 13:12 |
| tristan | Not buildstream-tests/bluetooth.bst | 13:12 |
| jonathanmaw | tristan: `bst track foundation/systemd.bst` is printing an ugly stack trace for me. the error message seems to be "pkg_resources.DistributionNotFound: BuildStream==0.1" | 13:14 |
| tristan | really ? | 13:14 |
| tristan | wat ?! | 13:14 |
| tristan | jonathanmaw, how can anything else work, then ? | 13:14 |
| jonathanmaw | here's the trace https://pastebin.com/sjJqs1a5 | 13:14 |
| jonathanmaw | aha, I've managed to funt gnome-system-image somehow, too | 13:15 |
| tristan | jonathanmaw, somehow you uninstalled buildstream or smth | 13:15 |
| jonathanmaw | all of buildstream seems to have been funted. maybe it was when I did `git clean -dfx` on the buildstream dir | 13:15 |
| tristan | jonathanmaw, that would do it yes | 13:15 |
| tristan | jonathanmaw, `pip install --user -e .` should fix | 13:16 |
| tristan | jonathanmaw, it *might* think it's already installed (due to cruft in ~/.local), if it does, then `pip uninstall buildstream` first | 13:16 |
| jonathanmaw | tristan: `pip3 install --user -e .` seems to be the proper invocation in my case. | 13:16 |
| tristan | yep | 13:16 |
| jonathanmaw | track succeded | 13:17 |
| tristan | jonathanmaw, thats the developer way, because then you never need to do anything whenever you modify a line of code (bst points to your checkout directory) | 13:17 |
| tristan | jonathanmaw, so `git diff -a` will show that bst found the latest commit sha for branch v232 :) | 13:17 |
| jonathanmaw | tristan: ok, so when working on source, I push it, and then `bst track <foo>` will fetch those changes and work out what the new ref is? | 13:20 |
| jonathanmaw | or is there a workflow which involves local clones of the source that gets tracked? | 13:21 |
| jonathanmaw | or when I have local source code do I use a "local" kind element? | 13:22 |
| tristan | jonathanmaw, a local source is a source which uses files from the project directory directly | 13:22 |
| jonathanmaw | ok, so if I have a local check out of source code, I need to push the changes to have the ref change. | 13:23 |
| tristan | jonathanmaw, the track feature is so that you can have a project which lists branch names for a bunch of sources, and then bst track can update them to 'latest-of-branch' automatically | 13:23 |
| tristan | Nope :) | 13:23 |
| tristan | Heh, this seems tricky | 13:23 |
| tristan | jonathanmaw, By "A local checkout of source code" I think you mean a "workspace" (https://wiki.gnome.org/Projects/BuildStream/Roadmap/Workspaces) | 13:24 |
| tristan | Those are not implemented yet, just put that idea aside for now | 13:24 |
| jonathanmaw | ah, ok. | 13:24 |
| tristan | jonathanmaw, a "local" source (I.e. the "local" source plugin)... is demonstrated by, for example in the 'build-gnome' branch, see the elements/initramfs/initramfs-scripts.bst element | 13:25 |
| tristan | jonathanmaw, I preferred to keep the initramfs init/shutdown scripts "in tree" instead of in a remote repository | 13:26 |
| jonathanmaw | tristan: Tarball Source in the roadmap says to use the host wget and the host tar to do the work. Is there any reason not to use the built-in python libraries instead? | 13:26 |
| tristan | you will find them directly in files/initramfs-scripts/ | 13:26 |
| tristan | jonathanmaw, strictly speaking no there is not | 13:27 |
| tristan | if you want to use built-in python stuff that is part of the standard lib, thats fine | 13:27 |
| tristan | jonathanmaw, at initial fetch time, if the tarball is not already downloaded, use plugin.tempdir() context manager for a temp directory to download to | 13:30 |
| tristan | and move the tarball in place after a download completes successfully | 13:30 |
| tristan | (which is essentially self.tempdir()) | 13:30 |
| jonathanmaw | Any thoughts on how to download tar files from places that use authentication? | 13:32 |
| jonathanmaw | Are we expecting to have to download tars from a place that uses basic auth? If so, how would we store username and password info? | 13:35 |
| jonathanmaw | given we don't want to commit that to git, I don't think we'd write it into the elements. | 13:36 |
| tristan | jonathanmaw, I am hoping that any such kind of auth can be done out of band, honestly | 13:37 |
| tristan | i.e. best would be something like scp | 13:37 |
| tristan | and exchange of public keys | 13:37 |
| jonathanmaw | ok, so I can skip auth with downloading tar files via http. | 13:38 |
| tristan | jonathanmaw, in the worst case, we can allow plugins to interrogate user configuration | 13:38 |
| tristan | but for right now yes, lets start with a tarball source that "works" first :) | 13:38 |
| tristan | jonathanmaw, note (not entirely related) that the ostree source allows loading of a public key in a project relative directory | 13:40 |
| tristan | but this is used only for certification of authenticity | 13:40 |
| tristan | not authentication of the downloader | 13:40 |
| tristan | (i.e. signature verification) | 13:40 |
| jjardon[m] | tristan: mmm, seems the new build call didnt work: https://gitlab.com/baserock/definitions/builds/14042286 | 13:41 |
| jjardon[m] | let me try with what you suggest last | 13:41 |
| tristan | jjardon[m], you should try this on a machine first before throwing this at gitlab runners no ? | 13:42 |
| * tristan is signing out for the night... | 13:43 | |
| tristan | jjardon[m], I have the impressions *something* is up with the elements/ subdir here | 13:43 |
| jjardon[m] | tristan: I though it would be easier to share build logs and also to have a pristine env every run; I will try locally as well | 13:45 |
| jonathanmaw | tristan: bonus! When using python's urllib, you can specify file:/// URIs, which removes the need to be connected to the internet to test it :) | 13:47 |
| *** tristan has quit IRC | 13:49 | |
| jjardon[m] | mmm, no luck: https://gitlab.com/baserock/definitions/builds/14045623#down-build-trace | 14:01 |
| jonathanmaw | Is there a way to run the tests for only one test file (e.g. tests/sources/git.py)? | 14:05 |
| jonathanmaw | editing python_files in setup.cfg to only point to the file I want doesn't seem to be enough | 14:06 |
| jonathanmaw | Ok, for tar, I think the source format is going to have the fields kind, url, and sha256. I can't make use of a "track" field because unlike git repos, an URL points to the entire thing. | 14:25 |
| jonathanmaw | so bst track <element> is going to update the sha256 field to be whatever the file's sha256sum is. | 14:26 |
| *** mattiasb has joined #buildstream | 14:30 | |
| ironfoot | jjardon[m]: that .bst file is under elements/gnome not under gnome/ | 14:37 |
| jjardon[m] | ironfoot: yup, tristan told me to change it, I was using "cd buildstream-tests && bst build elements/gnome/gnome-system-x86_64-content.bst" ; but seems that is not supported | 14:38 |
| ironfoot | bst -C buildstream-tests build elements/gnome/gnome-system-x86_64-content.bst | 14:38 |
| ironfoot | instead of bst -C buildstream-tests build gnome/gnome-system-x86_64-content.bst | 14:39 |
| jonathanmaw | hrm, not sure how set_ref and get_ref are meant to work if I don't have a field named 'ref'. I'm going to repurpose ref as the sha256sum. | 15:00 |
| jonathanmaw | and I should probably re-add "track", though I'm only expecting the value to be some variation on true or false. | 15:02 |
| jjardon[m] | ironfoot: nah, same problem as the beginning: https://gitlab.com/baserock/definitions/builds/14057708 | 15:38 |
| ironfoot | jjardon[m]: well, that's a different error "Could not find file at /builds/baserock/definitions/buildstream-tests/./bluetooth.bst" | 15:48 |
| ironfoot | it looks like the generated .bst files are a bit broken | 15:56 |
| jjardon[m] | ironfoot Its the same error when I first ask at 13:54 : https://gitlab.com/baserock/definitions/builds/14040020 :) I will try to compare them with the ones in the -test repo | 15:59 |
| ironfoot | jjardon[m]: oh true, I only saw your second and third build logs. | 16:01 |
| ironfoot | something is up with defs2bst, it might be good to have a look at what has been generated | 16:02 |
| ironfoot | BTW, interesting pipeline that one | 16:02 |
| jjardon[m] | my intention is to migrate all the baserock definitions that are in the CI atm and then use the output of that migration to build; so we can compare betwen ybd and buildstream (and also check the migration scripts work) | 16:25 |
| ironfoot | ++ | 16:26 |
| jonathanmaw | hooray for me! I have a substantial amount of code in a git repo somewhere https://gitlab.com/jonathanmaw/buildstream/tree/jonathan/tar-source (BIG NOTE: Nowhere near finished, I'm just feeling proud) | 16:37 |
| ironfoot | :) | 16:39 |
| ironfoot | jjardon[m]: this one works: http://paste.baserock.org/kiredusuza | 16:42 |
| ironfoot | basically, the defs2bst is not a very polished program :) | 16:43 |
| jjardon[m] | \o/ | 16:44 |
| * jjardon[m] tries | 16:44 | |
| ironfoot | main change: --output option | 16:44 |
| ironfoot | and also the `bst` call changed to remove "elements" | 16:45 |
| * jonathanmaw has an appointment with some kimchi. Cheerio! | 16:45 | |
| *** jonathanmaw has left #buildstream | 16:45 | |
| jjardon[m] | ironfoot: should https://gitlab.com/BuildStream/defs2bst/blob/master/README.rst be updated or its actually a bug? | 16:48 |
| ironfoot | hm.. given that readme, it's a bug | 16:49 |
| ironfoot | jjardon[m]: that error is new, but looks familiar (https://gitlab.com/baserock/definitions/builds/14065419) | 16:53 |
| ironfoot | I remember seeing it when running `bst` in docker some weeks ago (I didn't see it when running bst in docker today and yesterday) | 16:54 |
| jjardon[m] | mmm, at least seems we have progress :) I will look around | 17:02 |
| jjardon[m] | ironfoot: thanks for the help! | 17:02 |
| jjardon[m] | seems maybe we are hitting this? https://github.com/docker/docker/issues/1070 | 17:31 |
| *** ssam2 has quit IRC | 18:40 | |
| jjardon[m] | ironfoot: tristan I've opened https://gitlab.com/baserock/definitions/issues/9 | 19:01 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!