| *** franred has joined #buildstream | 07:16 | |
| *** tlater has joined #buildstream | 08:04 | |
| *** jude has joined #buildstream | 08:07 | |
| *** jonathanmaw has joined #buildstream | 08:16 | |
| *** ssam2 has joined #buildstream | 08:16 | |
| ssam2 | ah, once again out of memory running genattrtab | 09:18 |
|---|---|---|
| * ssam2 sets up a build VM | 09:19 | |
| *** franred has quit IRC | 10:14 | |
| *** franred has joined #buildstream | 10:29 | |
| *** franred has quit IRC | 10:35 | |
| *** franred has joined #buildstream | 10:40 | |
| tlater | Just to clarify the behavior of --except; It removes an element and ALL its dependencies not required by another element, unless it's the top-level element, in which case it only removes the top-level element, and keeps its dependencies. | 10:41 |
| ssam2 | the top-level element doesn't have any dependencies, surely? | 10:42 |
| ssam2 | other than that, sounds correct | 10:42 |
| tlater | Does it not? I thought it did, but that should make things easier then. | 10:42 |
| ssam2 | I'm picturing "top-level element" to mean the 'base dependency', which is usually the pre-built host tools | 10:43 |
| tlater | I might be thinking of the element tree in reverse, I think of it as the target specified on the CLI | 10:43 |
| tlater | The element generated for busybox bst if you call `bst bundle busybox.bst`, for example | 10:44 |
| ssam2 | ah right | 10:44 |
| ssam2 | also a valid interpretation | 10:45 |
| ssam2 | it wouldn't really make sense to run `bst bundle busybox.bst --except busybox.bst` | 10:45 |
| ssam2 | i'd say that's a user error | 10:45 |
| ssam2 | well, maybe there's a use case for it, i wasn't fully following your discussion with tristan yesterday | 10:45 |
| tlater | I might be misunderstanding things... | 10:46 |
| *** franred has quit IRC | 10:46 | |
| tlater | What should happen when I try to bundle busybox.bst, for example? | 10:47 |
| ssam2 | might depend what busybox.bst is, but i'd expect it to produce a bundle that would build BusyBox and all its dependencies | 10:48 |
| ssam2 | however, that wouldn't work because it'd pull in prebuilt host tools, which can't really be bundled | 10:48 |
| ssam2 | and it'd pull in an unnecessary compiler bootstrap | 10:48 |
| ssam2 | so in the world of Baserock definitions, you'd do something like `bst bundle busybox.bst --except gnu-toolchain/stage2.bst` | 10:49 |
| ssam2 | which chops off the stage2 of the bootstrap, which in turn removes stage1 of the bootstrap, and the host tools | 10:49 |
| tlater | And if busybox itself is a target that cannot be built, but has dependencies which the user wants to build? | 10:49 |
| ssam2 | why wouldn't you be able to build BusyBox ? | 10:50 |
| tlater | Some of these aren't build elements... | 10:50 |
| ssam2 | i don't understand what you mean by that | 10:51 |
| tlater | We have stack elements which seem to just be a way to collect elements | 10:51 |
| ssam2 | ah right, yeah | 10:52 |
| tlater | If I specify one of those as the target it cannot be built | 10:52 |
| ssam2 | yeah, good point | 10:52 |
| ssam2 | in that case it should just build all the dependencies | 10:52 |
| tlater | I suppose checking for stack elements makes sense | 10:52 |
| ssam2 | personally I'd consider that action to be the same as building the stack element | 10:52 |
| persia | I would also consider the assembly of component bits "building" the stack element. | 10:53 |
| persia | The same would apply to "building" static document elements. | 10:53 |
| *** franred has joined #buildstream | 11:02 | |
| *** tlater has quit IRC | 11:38 | |
| *** tlater has joined #buildstream | 11:39 | |
| ssam2 | hooray, I think I finally have a stage1-gcc build | 12:10 |
| tlater | \o/ | 12:11 |
| *** RXP has joined #buildstream | 12:19 | |
| tlater | Hm. For the --except stuff, is there a way to do this without performing a graph closure after the dependency tree has been built? | 12:19 |
| ssam2 | not sure. i haven't looked at the dependency code in Bst at all | 12:20 |
| tlater | Okay. Having more trouble with it than I thought I would :/ | 12:20 |
| *** RXP has quit IRC | 12:21 | |
| ssam2 | bah, just noticed BuildStream is currently fetching gnu-toolchain/stage2-linux-api-headers.bst and gnu-toolchain/linux-api-headers.bst | 12:30 |
| ssam2 | which are the same repo | 12:30 |
| ssam2 | but it's fetching it twice in parallel :/ | 12:31 |
| ssam2 | ah, it's https://gitlab.com/BuildStream/buildstream/issues/5 | 12:31 |
| jonathanmaw | hrm, trying to install bsdgames from the debian source is challenging | 12:40 |
| jonathanmaw | `debian/rules build` was hanging because it had an interactive prompt | 12:41 |
| jonathanmaw | also it's complaining about multiple definitions of getline. This is probably related to the patches that change getline to get_line | 12:41 |
| jonathanmaw | so now I need to figure out how to apply the patches. | 12:41 |
| tlater | I finally managed to get --except to work by retroactively removing dependencies \o/ Not sure if this is the way to go though... | 12:43 |
| ssam2 | sounds OK in principle | 12:43 |
| ssam2 | i'm quite liking the `bst track` workflow | 14:09 |
| ssam2 | there are still some minor issues in ruamel.yaml to clean up, but its so nice not having to copy and paste sha1 hashes everywhere | 14:09 |
| ssam2 | apart from when it updates refs in things I didn't want it to :/ | 14:10 |
| ssam2 | need to remember to use --deps=none | 14:10 |
| ssam2 | or maybe it's saving me from building a different ref than I expected, which is good I guesd | 14:10 |
| ssam2 | *guess | 14:11 |
| persia | jonathanmaw: For that package, the patches are stored in debian/patches in quilt(1). While not every package is compliant, packages are supposed to annotate the format in debian/source/format, with most as "3.0 (quilt)", as it is in this case. | 15:49 |
| persia | Generally, the result of running `dpkg-source -x ${something}.dsc` should result in the patches being applied, although not every package is either policy compliant or designed to be operated on by folk not the maintainer (who may have opinions that result in slightly altered workflows). | 15:50 |
| jonathanmaw | persia: yep | 15:52 |
| jonathanmaw | though having a look at some pages, the solution for that in particular seems to be to set QUILT_PATCHES=debian/patches, and call `quilt push` until it fails | 15:53 |
| jonathanmaw | bsdgames seems to have a specific problem that it gives "invalid argument" when it tries to chown the games to root:games. googling around throws up a load of stuff about nfs, so I'm guessing the overlayfs might be responsible somehow. | 15:57 |
| jonathanmaw | I'm working around it by sedding debian/rules to change them to root:root | 15:57 |
| jonathanmaw | and now I'm back to needing to mark dirs so that dpkg-deb can create them at an appropriate place | 15:59 |
| jonathanmaw | either that, configure them to put them somewhere else (maybe?), or replace dpkg-deb with a symlink to /bin/true | 16:00 |
| persia | `quilt push -a` saves having the loop in the calling program. | 16:00 |
| jonathanmaw | aha! | 16:01 |
| jonathanmaw | I didn't think of that | 16:01 |
| jonathanmaw | ta persia | 16:01 |
| persia | bsdgames uses setgid stuff, so be careful about granting the programs setgid root. | 16:02 |
| jonathanmaw | persia: yep, I wouldn't actually intend to use these on a running system. | 16:08 |
| *** tlater has quit IRC | 16:34 | |
| *** jonathanmaw has quit IRC | 16:41 | |
| ssam2 | yay, i have a gnu toolchain stack | 17:04 |
| ssam2 | i also like that I can `bst checkout gnu-toolchain ./tmp` and there it is | 17:05 |
| *** ssam2 has quit IRC | 17:15 | |
| *** persia has quit IRC | 18:47 | |
| *** waltervargas[m] has quit IRC | 18:54 | |
| *** jjardon[m] has quit IRC | 18:54 | |
| *** albfan[m] has quit IRC | 18:54 | |
| *** mattiasb has quit IRC | 18:54 | |
| *** jjardon[m] has joined #buildstream | 18:57 | |
| *** mattiasb has joined #buildstream | 20:15 | |
| *** tristan has quit IRC | 20:39 | |
| *** waltervargas[m] has joined #buildstream | 21:07 | |
| *** albfan[m] has joined #buildstream | 21:08 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!