| *** tristan has quit IRC | 00:06 | |
| *** tristan has joined #buildstream | 05:26 | |
| *** tristan has quit IRC | 06:24 | |
| *** ssam2 has joined #buildstream | 08:10 | |
| *** tlater has joined #buildstream | 08:12 | |
| *** jonathanmaw has joined #buildstream | 08:23 | |
| *** tristan has joined #buildstream | 08:52 | |
| tristan | tlater, I just noticed that your MR disappeared, but I just merged it, sorry :-S | 09:19 |
|---|---|---|
| tristan | tlater, after review I added a couple of changes too I'd like you to just briefly gloss over | 09:19 |
| tristan | https://gitlab.com/BuildStream/buildstream/commit/65aa3c8f87727b16f90df951f6fa458fbac2624b | 09:19 |
| tristan | https://gitlab.com/BuildStream/buildstream/commit/8e1fd9883036e94d4a205a2d378ccbc0471711c7 | 09:20 |
| tristan | https://gitlab.com/BuildStream/buildstream/commit/85c5d6aa522d13c2e452027b51d786eddda76dee | 09:20 |
| tristan | well the latter two are really the same change | 09:20 |
| tlater | Yup, I get the changes. | 09:28 |
| jonathanmaw | tristan: have you had time to look at https://gitlab.com/BuildStream/buildstream/merge_requests/30/diffs ? | 09:29 |
| tristan | jonathanmaw, ok so I think that's going to be correct | 09:37 |
| tristan | then again, wait | 09:38 |
| tristan | I've been going back and forth on this one :-/ | 09:38 |
| tristan | ah right | 09:39 |
| tristan | jonathanmaw, so the directory is created by the sandbox if ever the sandbox ran in advance of staging | 09:39 |
| tristan | which happens with integration commands | 09:39 |
| tristan | jonathanmaw, I've been hesitant about this issue mostly because I think it needs to be clarified in the Source API | 09:41 |
| tristan | jonathanmaw, ok so, right now we know that tarballs and gits also work fine if the directory already exists | 09:42 |
| tristan | I was a bit worried that it would break for git | 09:42 |
| tristan | but then again, at this point, we already know that running integration commands will cause the sandbox to create the build directory (as a result of it's mount mappings) | 09:42 |
| tristan | jonathanmaw, Ok so in that light, I think it makes more sense to do this in Source._stage() and not offload this uncertainty to source plugin authors | 09:43 |
| jonathanmaw | ok | 09:44 |
| tristan | jonathanmaw, on another topic, are you aware of: https://buildstream.gitlab.io/buildstream/buildstream.element.html#buildstream.element.Element.stage_artifact ? | 09:45 |
| tristan | jonathanmaw, i.e. I think you dont need to care about split rules, because that is taken into account by the stage_artifact() API | 09:46 |
| tristan | maybe you need to just get a list of the split domains on the public data, so you can selectively stage those to some subdirectories | 09:47 |
| jonathanmaw | tristan: currently, I'm just trying to make sure that those split-rules were set correctly | 09:49 |
| jonathanmaw | and it looks like the compose element uses stage_dependency_artifacts (hence stage_artifact), so that should be carried through | 09:50 |
| tristan | I thought you were specifying them manually ? | 09:50 |
| jonathanmaw | tristan: currently, yes | 09:50 |
| tristan | Because there is still no way to dynamically set the public data on elements, pending some more artifact work | 09:50 |
| tristan | right, compose uses the recursive artifact staging | 09:51 |
| tristan | while you will want a shallow one for generating packages | 09:51 |
| tristan | tlater, regarding some comments I read from yesterday; yes the build element builds into /buildstream/build and installs into /buildstream/install by default, and it cannot be overridden by a config file | 09:53 |
| tristan | tlater, that was why we discussed that we need an inventive way to override variable declarations at pipeline instantiation time, so that %{build-root} resolves to /build/${element_name} and %{install-root} resolves to / | 09:54 |
| tristan | so that we can generate scripts which build directly into the / of a foreign arch machine, or a chroot | 09:55 |
| tlater | Oh, okay, I understand. Shouldn't it be enough to use the defaults and copy to / for now though? | 09:55 |
| tlater | That is, hoping nothing uses the installation root for execution. | 09:56 |
| tristan | That can work yeah, so you have a master script which first moves a build dir into /buildstream/build and then moves the /buildstream/install into / | 09:56 |
| tlater | Yup, that's what I have at the moment | 09:57 |
| tristan | sure, no worries then, if it's not a problem on your side, then I think I actually prefer that | 09:57 |
| * tristan just touching base because he saw some commentary on that from irc | 09:58 | |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 7 commits (last: Add --except API) https://gitlab.com/BuildStream/buildstream/commit/2b1e6d7069e908aefc4720fb34b1e9c857664882 | 10:11 |
| gitlab-br-bot | buildstream: merge request (except->master: Add --except to fetch, track and show) #28 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/28 | 10:11 |
| tlater | ssam2: Mind having a look at my compile log? I've tried everything I can think of... | 10:21 |
| ssam2 | sure, paste it somewhere and I can have a look | 10:22 |
| tlater | The log: https://paste.codethink.co.uk/?2591 | 10:22 |
| tlater | Build script: https://paste.codethink.co.uk/?2593 | 10:22 |
| ssam2 | tlater, what version of glibc are you building there ? | 10:28 |
| ssam2 | try the release/2.25/master branch | 10:29 |
| tlater | Ok... Hang on, let me check what I am building | 10:30 |
| tlater | That's actually surprisingly hard to see from buildstream definitions | 10:31 |
| ssam2 | if the 'track:' field is accurate then it shouldn't be too hard | 10:31 |
| tlater | baserock/gnu-toolchain | 10:31 |
| tlater | :/ | 10:31 |
| ssam2 | ah, I think that's nonsense | 10:31 |
| ssam2 | replace it with 'release/2.25/master', then run `bst track gnu-toolchain/glibc.bst` | 10:32 |
| ssam2 | i've been building glibc 2.25 here with no problems (other than that musl issue which you shouldn't hit) | 10:32 |
| tlater | Ok, that would be neat, because then my scripts just work. | 10:32 |
| tlater | Which ref? | 10:33 |
| tlater | The current ref is obviously not in that branch... | 10:34 |
| ssam2 | `bst track` will update the 'ref' field for you | 10:34 |
| tlater | It complains about being unable to find the specified commit | 10:34 |
| ssam2 | did you update the 'track' field ? | 10:34 |
| tlater | Yup | 10:35 |
| ssam2 | hmm | 10:35 |
| tlater | url? | 10:35 |
| ssam2 | it's definitely there ... http://git.baserock.org/cgit/delta/glibc.git/log/?h=release/2.25/master | 10:35 |
| tlater | This one's tracking git://git.baserock.org/delta/, I think | 10:36 |
| tlater | Oh | 10:36 |
| tlater | Yeah... | 10:36 |
| tlater | I'll remove that source from the cache, that's helped before | 10:36 |
| ssam2 | that shouldn't be necessary | 10:40 |
| ssam2 | could you paste the exact .bst file and the error output from `bst track` ? this is something that has always worked for me .. | 10:40 |
| tlater | It might be a problem with my branch... | 10:41 |
| ssam2 | i think you do indeed need to update glibc by the way, this commit looks very much like it would solve the build problem: http://git.baserock.org/cgit/delta/glibc.git/commit/?h=release/2.25/master&id=d6d20de8b7ff6da6f3d29c5edb0ae3070f997f30 | 10:41 |
| ssam2 | hmm, although the warning might be harmless | 10:42 |
| ssam2 | but let's see | 10:42 |
| tlater | Yup :) I'll skip pasting the error, it should be easy to reproduce later | 10:43 |
| tlater | The warning is probably harmless, this just explicitly sets it to the default. | 10:46 |
| tlater | ^ commit | 10:47 |
| ssam2 | yeah | 10:47 |
| ssam2 | no idea about the next bits though; we've always been building GLIBC using Busybox tools | 10:47 |
| tlater | Whatever the error is, it's as if gcc is trying to compile the output of `mkdir --version` | 10:48 |
| ssam2 | right | 10:49 |
| gitlab-br-bot | buildstream: merge request (jonathan/fix-bzr-source->master: bzr source: Make sure the stage directory exists before bzr fetching) #30 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/30 | 10:49 |
| ssam2 | my build logs of glibc don't have any errors from mkdir | 10:49 |
| ssam2 | and are using busybox mkdir, although could be a different version of busybox | 10:50 |
| ssam2 | as an aside, a `bst shell --builddir=LATEST option would be really handy` :-) | 10:51 |
| ssam2 | maybe if you don't pass an arg to --builddir it could choose whatever builddir has the latest mtime | 10:51 |
| ssam2 | tlater, my busybox is 1.26.2 | 10:52 |
| tlater | Ah, I'm on 1.23.1 | 10:52 |
| tlater | I'll try building with this version first | 10:52 |
| tlater | Then probably switch busybox versions | 10:52 |
| tlater | The warning is gone, at least | 10:56 |
| tlater | No, still breaks. Other busybox version, it is! | 10:57 |
| tlater | I'll go have lunch while this builds... | 11:04 |
| tristan | ssam2, https://gitlab.com/BuildStream/buildstream/issues/40 is related to how the sandbox responds with SandboxFlags.INTERACTIVE | 11:20 |
| tristan | it needs to mount /dev/console,or /dev/tty (which cannot be assumed to exist on, say a gitlab runner)... | 11:21 |
| tristan | and that's not all | 11:21 |
| tristan | Something mysterious needs to be done for the shell to have a "real tty" and enable job control | 11:21 |
| ssam2 | is job control the thing that would make ctrl+c work as expected ? | 11:22 |
| *** tristan has quit IRC | 11:24 | |
| gitlab-br-bot | buildstream: issue #39 ("Enhancement: `bst shell --builddir` automatically picking the newest available builddir") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/39 | 11:31 |
| gitlab-br-bot | buildstream: issue #40 ("Ctrl+C causes `bst shell` to exit when I don't want it to") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/40 | 11:34 |
| ssam2 | there's a bit of a lag on that bot :-) | 11:41 |
| tlater | My libstdcxx isn't tracking :/ | 11:58 |
| gitlab-br-bot | buildstream: merge request (jonathan/fix-compose-no-integration->master: compose.py: Fix error when integration is false) #31 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/31 | 13:03 |
| jonathanmaw | tlater: are you still having the problem with libstdcxx? | 13:03 |
| tlater | Looks like it's the entirety of gcc, actually | 13:04 |
| jonathanmaw | tlater: hrm | 13:05 |
| jonathanmaw | are you getting an error message? | 13:05 |
| tlater | Yeah, this is one of them: https://paste.codethink.co.uk/?2594 | 13:06 |
| jonathanmaw | hrm, "unable to find commit for specified branch name 'baserock/gnu-toolchain'" | 13:06 |
| jonathanmaw | what branch of buildstream definitions are you using? build-gnome? | 13:06 |
| tlater | Not sure, it says delta | 13:07 |
| jonathanmaw | tlater: I'd like to have a look at it myself. I assume you're using the buildstream-tests repo. What branch of that are you using? | 13:07 |
| tlater | Not using buildstream-tests atm, but the definitions are the same as the gnu-toolchain branch's | 13:08 |
| ssam2 | he is hopefully using my sam/buildstream branch of definitions.git: | 13:08 |
| tlater | ^ | 13:08 |
| tlater | The strange thing is that I've managed to build with these definitions before | 13:09 |
| jonathanmaw | ssam2: ah, ok, that's in gitlab.com/baserock/definitions, by the look of it | 13:09 |
| ssam2 | yeah | 13:09 |
| ssam2 | i've just pushed a load of stuff to it | 13:10 |
| ssam2 | mostly for the stage1 and stage2 elements so might not change much, but i figure it's best if we keep in sync | 13:10 |
| tlater | I've changed the version of busybox from that branch to 1.26.2 | 13:10 |
| ssam2 | did it help ? | 13:10 |
| tlater | Can't get the base image to build... | 13:10 |
| tlater | But not because of that change | 13:10 |
| tlater | "image" | 13:11 |
| tlater | "chroot" | 13:11 |
| jonathanmaw | tlater: the specific problem there seems to be that it's looking in this repo http://git.baserock.org/cgit/delta/gcc-tarball.git/refs/heads | 13:11 |
| jonathanmaw | which doesn't have a branch named "baserock/gnu-toolchain" | 13:11 |
| tlater | I've tried changing that to gcc | 13:11 |
| tlater | and changing the branch to releases/2.25/master | 13:11 |
| ssam2 | there are a few things going on here... | 13:12 |
| ssam2 | firstly, you probably can --exclude everything before fhs-dirs | 13:12 |
| ssam2 | as the stage1 and stage2 bits will be already cross built when we are cross bootstrapping | 13:12 |
| ssam2 | second, the 'track' field needs to correspond to an actual git ref | 13:12 |
| ssam2 | the 'upstream:gcc-tarball' thing is probably a bit confusing | 13:13 |
| ssam2 | it's basically a keyed URI | 13:13 |
| tlater | Which uses the definition from project.conf, right? | 13:14 |
| ssam2 | if you look in project.conf you can see that 'upstream:' is defined as git://git.baserock.org/delta/ | 13:14 |
| ssam2 | yeah | 13:14 |
| ssam2 | so the repo for that component is: git://git.baserock.org/delta/gcc-tarball | 13:14 |
| tlater | And I'm looking for a branch from that | 13:14 |
| ssam2 | switch the git:// to a http:// and you can browse it in a browser and see what refs there are | 13:14 |
| tlater | Well, I've tried a few of those branches, just reset my local copy for that error log | 13:15 |
| ssam2 | gcc-tarball is a "special" case | 13:15 |
| ssam2 | we import tarballs of GCC into Git | 13:15 |
| tlater | That first bit works for cross-bootstrapping, yes, but I'm trying to get a chroot with busybox 1.26.2 to test if I can even get this to build | 13:15 |
| tlater | So --except isn't useful | 13:15 |
| ssam2 | and then manually add a couple of components, e.g.: http://git.baserock.org/cgit/delta/gcc-tarball.git/log/?h=baserock/gcc-7.1.0 | 13:15 |
| ssam2 | ah, OK | 13:15 |
| ssam2 | fair enough | 13:15 |
| ssam2 | in my branch I've updated the bootstrap to use GCC 7.1.0 | 13:16 |
| ssam2 | so maybe try rebasing your definitions changes onto the stuff I just pushed into the sam/buildstream branch | 13:16 |
| tlater | Have you pushed the branch? | 13:16 |
| tlater | Ah, ok | 13:16 |
| ssam2 | only just pushed it | 13:16 |
| tlater | By the way, does the value of track need to be escaped somehow? When I changed busybox's 1_23_1 to 1_26_2 it was concatenated to 1262, and failed, but with backslashes it seems to be fine | 13:23 |
| ssam2 | oh dear | 13:24 |
| ssam2 | probably a YAML thing | 13:25 |
| ssam2 | yes | 13:25 |
| ssam2 | not much we can do about that, YAML is a bit weird and places and the usual solution to add quotes | 13:25 |
| ssam2 | *a bit weird in places | 13:25 |
| tlater | Why on earth does 1_23_1 work? x) | 13:26 |
| ssam2 | it doesn't for me .. | 13:26 |
| ssam2 | $ echo '1_23_1' | python3 -c 'import yaml, sys; print(yaml.load(sys.stdin));' | 13:26 |
| ssam2 | 1231 | 13:26 |
| tlater | Huh, strange. The busybox definition should technically fail then. | 13:27 |
| tlater | Unless there is a branch 1231? | 13:27 |
| ssam2 | 'track' doesn't actually do anything when you run `bst build` | 13:27 |
| ssam2 | `bst build` follows the 'ref' field, `bst track` updates 'ref' based on the value of 'track' | 13:27 |
| ssam2 | but `track` is a pretty new feature so a lot of the 'track' refs are actually nonsense :-) | 13:27 |
| ssam2 | in Baserock for a long time we used to track branch names in the hope that such a feature would one day appear, in a field that had no actual meaning to any tool ... | 13:28 |
| ssam2 | and now `bst track` finally exists, but of course a lot of the data in the fields has never been tested | 13:28 |
| ssam2 | until recently you just had to copy the whole SHA1 around manually every time you wanted to change the version of a component | 13:28 |
| tlater | Well, at least I'm doing some testing here. | 13:29 |
| ssam2 | yeah :-) | 13:29 |
| tlater | What's going wrong here? | 13:44 |
| tlater | ``` | 13:45 |
| tlater | bst track gnu-toolchain/busybox.bst | 13:45 |
| tlater | Loading: 021 | 13:45 |
| tlater | Error loading pipeline: /home/tristanmaat/Documents/Projects/bl014/buildstream/buildstream/data/projectconfig.yaml [line 53 column 2]: Dictionary did not contain expected key 'bst-target-arch' | 13:45 |
| tlater | ``` | 13:45 |
| ssam2 | ah, sorry | 13:47 |
| ssam2 | this is because I told you to pull from my branch, but actually my branch requires the cross compile patch I've been working on :/ | 13:48 |
| ssam2 | might be easiest if I push that branch, it's finished apart from test fixups | 13:48 |
| tlater | Ok, gotcha. Can I simply replace all those with bst-arch? | 13:48 |
| ssam2 | you can | 13:48 |
| ssam2 | you can use gitlab.com/samthursfied/buildstream branch sam/host-and-target-arch to build if you want to avoid that | 13:49 |
| ssam2 | will hopefully get it ready for merge this evening | 13:49 |
| ssam2 | I need to nip out in about 40 minutes to go the dentist | 13:49 |
| tlater | I'd rather stick to my branch for now, I want to use source-bundle with this. | 13:49 |
| tlater | If I can't get it to work I'll switch | 13:50 |
| ssam2 | yeah I guess you'd have to merge the two together | 13:50 |
| tlater | Good luck with the dentist ;) | 13:50 |
| ssam2 | although it's only one commit so not too complex | 13:50 |
| ssam2 | thanks ... | 13:50 |
| * ssam2 fingers crossed | 13:50 | |
| jonathanmaw | well, that's interesting. I printed a list of files from Element.__compute_splits(), and it broke the build. Apparently because it's a generator. | 13:50 |
| jonathanmaw | making sure the generator produces a list before using it twice solved that problem :/ | 13:51 |
| tlater | Stupid generators. Never do what you want them to do. | 13:51 |
| tlater | ssam2: You missed stage2-gcc-fixed-headers' track. | 14:08 |
| ssam2 | ah, i probably did | 14:11 |
| ssam2 | seems not to have broken anything, but worth fixing | 14:12 |
| tlater | Still fails to compile :/ I didn't build the exact same environment, because alpine is local on ssam2's machine, so that may well be the issue. | 15:53 |
| tlater | The build fails to complete stage1-gcc now, with the beautiful error that my compiler cannot create executables | 15:54 |
| tlater | I got one that I think is going to finish \o/ No time to wait for it anymore though. | 16:22 |
| *** tlater has quit IRC | 16:24 | |
| *** jonathanmaw has quit IRC | 16:35 | |
| *** jude has quit IRC | 17:27 | |
| *** ssam2 has quit IRC | 20:13 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!