| *** Prince781 has joined #buildstream | 01:11 | |
| *** Prince781 has quit IRC | 01:23 | |
| *** Prince781 has joined #buildstream | 01:29 | |
| *** Prince781 has quit IRC | 01:31 | |
| *** Prince781 has joined #buildstream | 01:32 | |
| *** mcatanzaro has quit IRC | 03:29 | |
| *** Prince781 has quit IRC | 05:41 | |
| *** tristan has joined #buildstream | 07:40 | |
| *** xjuan has quit IRC | 07:44 | |
| *** xjuan has joined #buildstream | 07:45 | |
| *** tm has joined #buildstream | 08:45 | |
| *** toscalix has joined #buildstream | 08:46 | |
| *** jonathanmaw has joined #buildstream | 08:55 | |
| *** valentind has joined #buildstream | 09:09 | |
| *** ssam2 has joined #buildstream | 09:37 | |
| *** aday has joined #buildstream | 09:53 | |
| *** dominic has joined #buildstream | 10:00 | |
| *** valentind has quit IRC | 10:54 | |
| gitlab-br-bot | buildstream: issue #262 ("Information about host machine architecture leaks into sandbox") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/262 | 11:50 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (sam/doc-sandbox->master: doc: Add 'sandboxing' section) #279 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/279 | 11:52 |
| gitlab-br-bot | buildstream: merge request (sam/doc-sandbox->master: doc: Add 'sandboxing' section) #279 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/279 | 11:58 |
| *** ironfoot has quit IRC | 12:08 | |
| *** ironfoot has joined #buildstream | 12:16 | |
| *** ChanServ sets mode: +o ironfoot | 12:17 | |
| gitlab-br-bot | buildstream: issue #263 ("Allow checking out an artifact as a 'tar' stream") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/263 | 12:19 |
| *** xjuan has quit IRC | 12:28 | |
| *** ironfoot has quit IRC | 12:30 | |
| *** ironfoot has joined #buildstream | 12:42 | |
| gitlab-br-bot | buildstream: issue #172 ("pkg_resources module causes a delay of between 0 and many seconds every time `bst` starts up") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/172 | 12:52 |
| gitlab-br-bot | buildstream: merge request (sam/doc-sandbox->master: doc: Add 'sandboxing' section) #279 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/279 | 13:15 |
| gitlab-br-bot | buildstream: issue #109 ("Add 'flatpak' element to allow generating flatpak apps and runtimes") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/109 | 13:34 |
| jjardon[m] | Uh , did bst grew a flatpak element? ^ | 13:38 |
| gitlab-br-bot | buildstream: issue #255 ("Document sandbox/artifact cache limitations") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/255 | 13:38 |
| gitlab-br-bot | buildstream: merge request (sam/doc-sandbox->master: doc: Add 'sandboxing' section) #279 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/279 | 13:38 |
| tlater | jjardon[m]: It was merged to bst-external | 13:39 |
| ssam2 | jjardon[m], it's just a copy of the one from freedesktop-sdk | 13:41 |
| ssam2 | works for building apps too, see https://mail.gnome.org/archives/buildstream-list/2018-February/msg00011.html | 13:41 |
| tristan | jjardon[m], you have good privileges in bst-external repo; for the short term at least - you can feel free to just modify it at will | 13:46 |
| tristan | jjardon[m], longer term we'll want it to be more stable and not drastically changing, of course | 13:47 |
| jjardon[m] | Cool, is there any plan for a bst-external tag/release? | 13:48 |
| * tristan has a "decent" working prototype of project.refs, but it needs: A.) optionality (otherwise it's API break)... B.) more thought for junctions | 13:48 | |
| tristan | jjardon[m], currently no; vision is a bit blurry; it's possible though that we dont want to do that in bst-external | 13:49 |
| persia | I think it makes sense to never release bst-external | 13:50 |
| tristan | jjardon[m], the reason being that, currently things which live there are both A.) Pretty case specific ... and B.) Not well analyzed enough yet to be stable | 13:50 |
| juergbi | tristan: do you want input from me regarding handling of refs for junctions? | 13:50 |
| tristan | jjardon[m], pretty much for the reason of (B) above, I'm thinking we may want to instead wait a time period and then migrate plugins which become stable to some other, more specific repos | 13:50 |
| jjardon[m] | OK, problem here is that I need to tell my users what version of bst-external they should use, and a SHA is not very human friendly | 13:51 |
| juergbi | date-based tags? | 13:51 |
| juergbi | 18.02 or so? | 13:51 |
| tristan | That could be an option | 13:52 |
| jjardon[m] | That would work for me | 13:52 |
| tristan | If tags are desired in a scenario without hard API stability guarantees | 13:52 |
| persia | juergbi: Problem being that doing so encourages updates by consumers, which may not be ideal if the repo isn't under some sort of release governance. | 13:52 |
| * persia is not convinced anyone would appreciate that date-based-tags aren't supported releases | 13:53 | |
| tristan | well, fair point I guess | 13:53 |
| juergbi | an alternative could be to import bst-external as submodule into freedesktop-sdk | 13:53 |
| persia | I think the better answer is to polish the plugin as appropriate and put it somewhere that does have releases, etc. | 13:53 |
| tristan | persia, well yeah, we're talking about the time it takes for that to be appropriate | 13:54 |
| persia | But that is related to my conception of bst-external as an ungoverned collaboration space: I don't know if others share this concept. | 13:54 |
| tristan | I dont think it's reasonable to think that flatpak plugin YAML format will be API stable before trying to use it for a few months | 13:54 |
| persia | tristan: Understood. My thought is that if we need unstable software, we should use a SHA (as ugly as this might be), and work to make it stable. | 13:55 |
| persia | There's not enough folk involved for us vs. them to be a big factor, really. | 13:55 |
| * tristan is rather ambivalent on this point | 13:55 | |
| persia | Unless someone has a specific audience in mind as the users of a plugin before it is stable, where that audience cannot be encouraged to help make it stable. | 13:55 |
| jjardon[m] | A tag can mark an unstable version as well ... | 13:56 |
| tristan | juergbi, I think for project.refs, what I think I need is (A) from the TrackQueue, I need to know what is the frontend/toplevel project being built (there is probably a pointer hanging around for that) | 13:56 |
| tristan | juergbi, and (B), I think the right approach here is that 'subproject' refs stored in project.refs are only ever useful from the toplevel project being built (i.e. we never consult the subproject refs found in project.refs files in subprojects recursively) | 13:57 |
| tristan | juergbi, still in pondering stage here but that is sort of the tricky part | 13:57 |
| persia | jjardon[m]: Technically, yes, but man folk fail to understand that: the x.even/x.odd naming scheme confuses people regularly, as they want to "upgrade" to x.odd, and then complain when it breaks. | 13:57 |
| persia | s/man/many/ | 13:58 |
| tristan | persia, I have never really had time to sympathize with folks who dont understand even/odd stable/unstable versioning schemes, rather when questions pop up over the years, we just inform how versioning works in project "foo" | 13:59 |
| tristan | I'm not sure it's the best approach either to tip-toe around what we think people might randomly perceive a tag to mean | 14:00 |
| juergbi | tristan: (A) you could take the first entry of context._get_projects() if that's available | 14:00 |
| persia | tristan: Such an explanation works well when there are proper releases. For something that never releases (and never intends to release), especially in the case where any feature is lost once it becomes stable, I think it behooves us to consider naive perceptions. | 14:00 |
| juergbi | otherwise Pipeline has a ref, of course, might have to pass it in | 14:00 |
| tristan | persia, but still, rather ambivalent, I would like to leave this decision up to jjardon[m], as he is the one with practical needs today. | 14:01 |
| * persia is mostly concerned about complaints that "bst-external 18.08 is broken because buildstream no longer supports flatpaks" | 14:01 | |
| *** tristan has quit IRC | 14:06 | |
| jonathanmaw | nexus: would you like me to review https://gitlab.com/BuildStream/bst-external/merge_requests/19 ? | 14:12 |
| *** tristan has joined #buildstream | 14:13 | |
| *** tm has quit IRC | 14:13 | |
| nexus | jonathanmaw: i just need to make a quick alteration, after that, yes pls | 14:18 |
| nexus | ok, done, yes please jonathanmaw | 14:19 |
| juergbi | tristan: (B) if we assume that project.refs will mainly be used outside version control, that makes sense | 14:21 |
| juergbi | otherwise not sure | 14:21 |
| tristan | I would not assume that | 14:21 |
| tristan | (B) is certainly tricky | 14:21 |
| tristan | the more I think of it | 14:21 |
| tristan | Well, maybe not so much | 14:21 |
| juergbi | hm but if a project uses project.refs as main way to track refs and has that in vcs; it needs to be usable the same way as inline refs | 14:22 |
| tristan | Assume that a master project is allowed to override what a subproject said it's refs should be | 14:22 |
| *** jonathanmaw has quit IRC | 14:23 | |
| tristan | However, it's a bit rude that a simple `bst track --deps all` without --except on junction points will track every subproject recursively | 14:23 |
| *** jonathanmaw has joined #buildstream | 14:23 | |
| jonathanmaw | ah, I thought gitlab had gone down. nope, just my internet. | 14:23 |
| juergbi | agreed, i think track shouldn't go across junctions by default | 14:24 |
| tristan | juergbi, It means also that at load time; we need to squash active refs which exist in subproject's project.ref files (or inline) | 14:24 |
| tristan | Yeah maybe something explicit should be introduced for descending into junctions at tracking time | 14:24 |
| tristan | juergbi, what also boggles my mind; I'm not sure what happens in a recursive track session currently | 14:26 |
| juergbi | i actually forgot to check but i guess it updates the temp directory | 14:27 |
| tristan | juergbi, when you track a junction element, it will upgrade the subproject and then the elements which need tracking have changed in mid-flight ? | 14:27 |
| juergbi | ah no, tracking recursively will only track regular elements, not junctions themselves | 14:27 |
| juergbi | junctions can only be tracked explicitly at this point | 14:27 |
| tristan | Oh ? | 14:27 |
| juergbi | junctions can't be dependencies, so they are also never in a plan etc | 14:28 |
| tristan | Okay, that is... more tricky than the changes I'm making, but sounds pretty non-symmetric | 14:28 |
| tristan | Oh wait, maybe I misunderstand; yes this sounds right | 14:28 |
| tristan | So you have elements which depend *into* junctions | 14:28 |
| juergbi | yes | 14:29 |
| juergbi | and those can be tracked | 14:29 |
| tristan | but you cannot depend on a junction, yet; a junction is still an element | 14:29 |
| juergbi | right | 14:29 |
| tristan | Hmmm | 14:29 |
| juergbi | you should get a sensible error message if you try | 14:29 |
| tristan | I feel/suspect that we need a way to bring these junction elements into the pipeline - at least in some ways | 14:30 |
| juergbi | for tracking or other reasons? | 14:31 |
| tristan | for instance; it's possible right now that if we use a project with junctions and build it; the build session log will fail to print out the cache keys for the junctions themselves | 14:31 |
| tristan | at least there | 14:31 |
| juergbi | ok but they are also not too relevant | 14:32 |
| tristan | What happens when you `bst build junction.bst` ? | 14:32 |
| juergbi | should result in an error | 14:33 |
| tristan | Ok | 14:33 |
| juergbi | we could support it if we had a default target | 14:33 |
| juergbi | for a project | 14:33 |
| tristan | Nah | 14:33 |
| tristan | I think though we may need some API churn around this to make things a bit more clear | 14:33 |
| tristan | or maybe a different file extension or smth | 14:34 |
| tristan | they behave much like an element, yes from the core's perspective, this makes sense because we leverage the featuresets we need | 14:35 |
| juergbi | possibly. we discussed this a while ago but the conclusion back then was to just use .bst | 14:35 |
| tristan | from a user perspective, it's a bit confusing | 14:35 |
| tristan | well, I think anyway I have to get used to using them :) | 14:35 |
| tristan | with more use, we will be able to form better opinions | 14:36 |
| juergbi | i've found an interesting (ab)use of junctions | 14:36 |
| tristan | luckily this is still early 1.1 cycle, so we have a lot of discovery time | 14:36 |
| juergbi | use a local path: . junction to depend on the same project with different options | 14:36 |
| juergbi | useful for multiple bootstrapping stages | 14:36 |
| tristan | Yeah | 14:37 |
| tristan | I thought of another thing which might be an interesting use of junctions | 14:37 |
| gitlab-br-bot | buildstream: issue #264 ("The build environment should set UTF-8 by default") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/264 | 14:38 |
| tristan | persia, and I were discussion the weird situations which arise where "Software stacks are rather vertical dependency wise, and it makes sense to split projects by stack layer" | 14:38 |
| tristan | *but* | 14:38 |
| tristan | organizations generally want to manage a set of modules, sprinkled across the stack (an out of tree kernel module here, a middleware library there, and some full on GUI apps) | 14:39 |
| tristan | that's a drastic case where it's not really recommendable to maintain one project with those components, but there is gray area | 14:39 |
| persia | Is this about creating a project that depends on several upstream projects and then modifies only a couple of things in the middle? | 14:40 |
| tristan | juergbi, so I was thinking, maybe it's possible to have freedesktop-sdk build glib from GNOME, for freedesktop-sdk level things which depend on glib | 14:40 |
| tristan | and then also have GNOME depend on freedesktop for things which in turn depend on it's glib | 14:41 |
| juergbi | hm | 14:41 |
| tristan | juergbi, maybe that's "going too far" with junctions, though; maintainability wise; even if it worked | 14:41 |
| juergbi | one potential issue here is that we don't support doing this forth and back without actually loading the top-level project twice | 14:42 |
| juergbi | we generally support the coalescing of subprojects for nested subprojects but not between the top-level and a subproject | 14:43 |
| juergbi | (as there is no junction name to match to for the top-level project) | 14:43 |
| tristan | right, resolving the correct refs and project state becomes difficult | 14:44 |
| tristan | or not resolving them, but synchronizing them | 14:44 |
| tristan | and there is no sensible way for a subproject to refer to "The project which included me" | 14:44 |
| juergbi | indeed | 14:45 |
| juergbi | tristan: btw: i was thinking about cross compilation over the weekend and i believe a scratchbox-like approach (also using qemu-user + cross compiler but much simpler) could still be feasible and reliable | 14:51 |
| persia | I don't really like the idea of projects depending on each other (circular dependency loops are bad). | 14:58 |
| persia | On the other hand, I think GNOME should be able to override the freedesktop-sdk glib definition (if appropriate), and then reuse other definitions in freedesktop-sdk, such that GNOME binaries are subtly different (as everything is built against GNOME glib). | 14:59 |
| juergbi | yes, i also don't think cycles really make sense in general | 14:59 |
| persia | But that the GNOME project *does not* need to redefine anything else in freedesktop-sdk: the other definitions just get used as-is (except consuming the GNOME glib as a dependency vs. the freedesktop glib) | 15:00 |
| persia | This does mean different cache keys, but since they are different objects, that's probably a good thing. | 15:00 |
| juergbi | overriding a single element in the subproject is not possible at this point | 15:01 |
| persia | For me, that would be a killer feature. | 15:02 |
| tristan | juergbi, interestingly, the scratchbox approach was approximately the most hacked out, contorted way I could possibly find to do cross compilation (http://www.merproject.org/~lbt/SB2_internals_1st_ed_20120425.pdf) | 15:02 |
| juergbi | persia: it's definitely interesting. having junction config for this should be possible | 15:03 |
| tristan | it is a challenge to come up with a less maintainable design :) | 15:03 |
| persia | juergbi: That would be really cool, as it should allow us to avoid the circular dependency issue. | 15:04 |
| persia | Otherwise we end up with different people arguing about what features to enable in a given source, which limits definition reuse. | 15:04 |
| tristan | juergbi, that said; I did experiment with something similar, qemu + distcc to well known cross compiler (from the same build which was used to construct the runtime) | 15:04 |
| tristan | juergbi, build farm approach seems to me still cleaner | 15:05 |
| juergbi | persia: yes, i could certainly see it being useful but we have to think about whether such connected projects would still be reliably maintainable | 15:06 |
| juergbi | tristan: i prefer qemu-user + in-tree cross compiler in disguise to qemu + distcc. should be much easier to manage and even more efficient. but it certainly goes into the same direction | 15:07 |
| juergbi | build farm: sure, that's fine for cases where you can have a reasonable one for the target ISA | 15:07 |
| tristan | we're going to break all sorts of sandboxing rules I think if we go down into scratchbox territory | 15:08 |
| juergbi | i don't want to build webkitgtk natively on ARM, though, not even with a buildfarm | 15:08 |
| juergbi | no, i think it should be possible without breaking any rules | 15:08 |
| juergbi | except for qemu-user registration | 15:09 |
| tristan | if we ever do an LD_PRELOAD in a build environment, then we're bust | 15:09 |
| juergbi | no, that shouldn't be necessary | 15:09 |
| tristan | that's what scratchbox is doing | 15:09 |
| juergbi | i know. i definitely don't want to recreate scratchbox | 15:09 |
| tristan | but yeah, qemu-user mode; maybe; but if we can do build-farm I'm not sure it's right | 15:10 |
| tristan | i.e. once down that path, you are presented with the world of "cheats" you can decide to do, or not, to optimize build time | 15:10 |
| tristan | if you dont do the cheats, I'm not sure you get better performance than a build-farm approach | 15:11 |
| juergbi | to some extent yes but stripping down the 'cheats' to the bare minimum could result in a sensible compromise | 15:11 |
| tristan | juergbi, a remote worker implemented as a portal into a local qemu-user session might be interesting, though | 15:11 |
| juergbi | building everything via emulation is too slow in practice, imo | 15:12 |
| tristan | Yes | 15:12 |
| tristan | And the cross compiler thing... ehhh; I dont think we want to go there unless we really really have to | 15:12 |
| tristan | that will be a *lot* of design to get something well defined | 15:13 |
| juergbi | i don't think it needs that much infrastructure but maybe i'm forgetting something | 15:13 |
| juergbi | i did some experiments a few years ago which worked pretty well | 15:13 |
| tristan | It needs to be a cross compiler that we built | 15:13 |
| juergbi | yes, of course | 15:14 |
| juergbi | with the approach i'm thinking of, the cache key would depend on the actual build host architecture | 15:14 |
| juergbi | but i think that's acceptable | 15:14 |
| juergbi | it's just a cache | 15:14 |
| tristan | well, there is no guarantee that the output is the same anyway | 15:14 |
| juergbi | indeed nothing that buildstream can control | 15:15 |
| juergbi | in practice, i expect/hope it to be reliable | 15:15 |
| juergbi | i.e., bit-for-bit reproducible | 15:15 |
| tristan | so that's a sensible choice (i.e. cross-compile from x86 vs cross-compile from arm, vs native compile on real mips... as far as we're concerned; they are all different binaries) | 15:15 |
| juergbi | (with native compilation) | 15:15 |
| tristan | well, sounds like a plausible sandbox implementation; but would require much experimentation too; I'm not personally clear on how you invoke native binaries in a qemu-user session for cross compile | 15:17 |
| tristan | also; you need to have a properly tuned compiler, which we recently discovered yocto does not (iirc, the native compiler it installs on ${target} still needs to be told about it's target board features) | 15:19 |
| tristan | the aboriginal gcc builds are probably better in this regard | 15:19 |
| juergbi | qemu-user is per process | 15:19 |
| juergbi | tuning shouldn't really differ between native and cross compilers | 15:19 |
| juergbi | assuming you don't use -mtune=native | 15:19 |
| tristan | I mean, you build a cross compiler for arm with vfp3 and neon enabled | 15:20 |
| tristan | and when you use that cross compiler, you dont have to specify the features | 15:20 |
| juergbi | yes but that's the same as for a native compiler | 15:21 |
| tristan | except that we dont have cross build models to compare (that I know of) where we've seen this work all the way up the stack | 15:21 |
| tristan | (hence, experimentation) | 15:22 |
| juergbi | i'll try to hack something up in the evening or weekend | 15:22 |
| tristan | juergbi, actually, from what I'm gathering now; it sounds like you dont need a special sandbox for this | 15:22 |
| tristan | you just build-only depend on qemu user mode and the cross compiler that you build, in the sandbox | 15:23 |
| juergbi | no, no special sandbox required | 15:23 |
| tristan | and voiala | 15:23 |
| juergbi | no, qemu-user registration is the exception | 15:23 |
| juergbi | that has to happen on the host as root | 15:23 |
| juergbi | you can think of it like installing an ARM co-processor ;) | 15:23 |
| juergbi | it might be possible to do it in a namespace in the future | 15:24 |
| juergbi | otherwise you'd have to trap execve but i consider this wasted given that there is binfmt_misc, at least on linux | 15:24 |
| jonathanmaw | nexus: I'm finished reviewing your merge request. | 15:24 |
| nexus | yay | 15:25 |
| nexus | did i fail? | 15:25 |
| jonathanmaw | nexus: well, the tests fail, but it looks like that's a small fix | 15:26 |
| nexus | kk, shall look | 15:28 |
| *** mcatanzaro has joined #buildstream | 15:33 | |
| *** tristan has quit IRC | 15:38 | |
| *** tristan has joined #buildstream | 15:38 | |
| *** manj-gnome has joined #buildstream | 16:31 | |
| manj-gnome | Hello | 16:31 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: WIP: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 16:32 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: WIP: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 16:49 |
| persia | manj-gnome: Hi. | 16:49 |
| *** manj-gnome has quit IRC | 16:50 | |
| *** toscalix has quit IRC | 17:00 | |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: WIP: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 17:19 |
| *** noisecell has quit IRC | 17:31 | |
| *** Prince781 has joined #buildstream | 17:38 | |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: WIP: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 17:39 |
| *** xjuan has joined #buildstream | 17:49 | |
| adds68 | Is there a way to see error logs from a previous build? | 17:52 |
| ssam2 | look in the cache directory | 17:53 |
| ssam2 | there's a logs/ subdir | 17:53 |
| ssam2 | you need to know the cache ID of the build, or look at the timestamps | 17:54 |
| *** ssam2 has quit IRC | 17:58 | |
| *** dominic has quit IRC | 18:00 | |
| *** bochecha has left #buildstream | 18:03 | |
| *** jonathanmaw has quit IRC | 18:03 | |
| adds68 | cheers ssam2 | 18:04 |
| *** Prince781 has quit IRC | 18:22 | |
| *** Prince781 has joined #buildstream | 20:34 | |
| *** mcatanzaro has quit IRC | 20:55 | |
| *** aday has quit IRC | 21:03 | |
| *** Prince781 has quit IRC | 21:27 | |
| *** Prince781 has joined #buildstream | 21:29 | |
| *** Prince781 has quit IRC | 21:35 | |
| *** Prince781 has joined #buildstream | 21:40 | |
| *** mcatanzaro has joined #buildstream | 21:43 | |
| *** valentind has joined #buildstream | 21:54 | |
| *** xjuan has quit IRC | 22:27 | |
| *** Prince781 has quit IRC | 22:46 | |
| *** tristan has quit IRC | 22:59 | |
| *** Prince781 has joined #buildstream | 23:17 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!