| *** jennis has joined #buildstream | 00:19 | |
| *** jennis_ has joined #buildstream | 00:19 | |
| *** Prince781 has joined #buildstream | 02:47 | |
| *** Prince781 has quit IRC | 03:00 | |
| *** jennis has quit IRC | 03:07 | |
| *** jennis_ has quit IRC | 03:07 | |
| *** Prince781 has joined #buildstream | 03:30 | |
| *** tristan has joined #buildstream | 04:34 | |
| *** Prince781 has quit IRC | 04:55 | |
| *** Prince781 has joined #buildstream | 04:58 | |
| *** Prince781 has quit IRC | 05:05 | |
| *** Prince781 has joined #buildstream | 05:07 | |
| tristan | albfan[m], I'm tidying up your example, I've squashed some fixes to the tests into your commit, and and making some additional changes on top of that commit | 05:28 |
|---|---|---|
| tristan | albfan[m], also, gave you 'developer' user so you dont need to work with obnoxious forks (you can push to `albfan/<topic-branch-name>` branches for merge requests) | 05:29 |
| tristan | I'm going to remove the README.md, I think it's redundant to document it twice | 05:29 |
| paulsherwood | tristan: in gitlab, a readme.md is the default page rendered on the repo view... are you sure you want to delete it? | 05:44 |
| *** ernestask has joined #buildstream | 05:53 | |
| tristan | paulsherwood, it's in a deep doc/examples subdir | 06:00 |
| tristan | paulsherwood, we want the examples integrated into docs, if we add another README.md there, it should not redundantly talk about what we're already talking about in the docs | 06:01 |
| albfan[m] | tristan: Thanks a lot, I will review your changes. I will discuss with jennis because MR 323 is the place where we should collaborate for the getting started docs. | 06:06 |
| paulsherwood | tristan: ack, sorry for the noise | 06:07 |
| tristan | albfan[m], I'm going to bypass that for now | 06:08 |
| tristan | albfan[m], I see this example as orthogonally applicable, and I want to put an end to all the fuss | 06:08 |
| tristan | albfan[m], I'm grateful that you put in the effort, really | 06:09 |
| albfan[m] | hehe. Explain BuildStream have to create some fuss. I was really puzzled by test so nice you find time for it. Somebody ask me for an example with extensions (java, rust) Any other example (under CI) to work on? | 06:12 |
| *** Prince781 has quit IRC | 06:27 | |
| gitlab-br-bot | buildstream: merge request (tristan/flatpak-example->master: Adding the flatpak autotools example) #466 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/466 | 06:29 |
| gitlab-br-bot | buildstream: merge request (gitignore->master: .gitignore: Ignore autogenerated docs) #464 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/464 | 06:30 |
| gitlab-br-bot | buildstream: merge request (tristan/flatpak-example->master: Adding the flatpak autotools example) #466 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/466 | 06:31 |
| *** Prince781 has joined #buildstream | 06:34 | |
| tristan | Crap, one blocker is the setuptools bug | 06:45 |
| tristan | I was *almost there* | 06:46 |
| tristan | What to do... | 06:46 |
| tristan | I want to solve this in < 15min... | 06:46 |
| *** Prince781 has quit IRC | 06:56 | |
| gitlab-br-bot | buildstream: merge request (tristan/flatpak-example->master: Adding the flatpak autotools example) #466 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/466 | 07:02 |
| gitlab-br-bot | buildstream: merge request (wip/examples->master: WIP: doc: Add examples) #463 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/463 | 07:04 |
| gitlab-br-bot | buildstream: merge request (tristan/flatpak-example->master: Adding the flatpak autotools example) #466 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/466 | 07:30 |
| *** ernestask has quit IRC | 07:31 | |
| *** ernestask has joined #buildstream | 07:31 | |
| *** tristan has quit IRC | 07:35 | |
| *** toscalix has joined #buildstream | 07:40 | |
| *** tristan has joined #buildstream | 07:49 | |
| gitlab-br-bot | buildstream: merge request (tristan/flatpak-example->master: Adding the flatpak autotools example) #466 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/466 | 07:52 |
| gitlab-br-bot | buildstream: merge request (tristan/flatpak-example->master: Adding the flatpak autotools example) #466 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/466 | 08:21 |
| gitlab-br-bot | buildstream: merge request (juerg/googlecas->master: WIP: Google CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/337 | 08:29 |
| *** bethw has joined #buildstream | 08:30 | |
| gitlab-br-bot | buildstream: merge request (juerg/googlecas->master: WIP: Google CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/337 | 08:32 |
| *** slaf has quit IRC | 08:37 | |
| *** jonathanmaw has joined #buildstream | 08:58 | |
| gitlab-br-bot | buildstream: merge request (juerg/googlecas->master: WIP: Google CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/337 | 09:05 |
| Nexus | tristan: So, looking over our conversation yesterday about the stream._fetch() function. It looks like i'm going to have to seperate `track` out from that function, so it can be calling seperately from the rest of the function. But in eaither case, `--track` has to be available to both cached and non-cached calls, regardless of if a fetch is wanted. Is this how you see it? | 09:09 |
| *** slaf has joined #buildstream | 09:12 | |
| *** slaf has joined #buildstream | 09:13 | |
| *** slaf has joined #buildstream | 09:13 | |
| *** slaf has joined #buildstream | 09:13 | |
| *** slaf has joined #buildstream | 09:13 | |
| *** slaf has joined #buildstream | 09:14 | |
| *** slaf has joined #buildstream | 09:14 | |
| *** slaf has joined #buildstream | 09:14 | |
| *** slaf has joined #buildstream | 09:14 | |
| *** slaf has joined #buildstream | 09:15 | |
| tristan | Nexus, I made the suggestion yesterday that you might either not use the internal helper Stream._fetch() function, or you might give it the option of only tracking | 09:19 |
| tristan | Nexus, currently it either does fetch, or fetch & track | 09:19 |
| *** dominic has joined #buildstream | 09:22 | |
| *** aday has joined #buildstream | 09:24 | |
| *** finn has quit IRC | 09:35 | |
| *** finn has joined #buildstream | 09:35 | |
| tristan | So, it aint perfect, but it's a good start: http://buildstream.gitlab.io/buildstream/examples_flatpak_autotools.html | 09:38 |
| *** finn has quit IRC | 09:38 | |
| *** finn has joined #buildstream | 09:38 | |
| tristan | It could use some more preliminary text explaining that the explained elements need to be created, or at least have a link to the example directory here: https://gitlab.com/BuildStream/buildstream/tree/master/doc/examples/flatpak-autotools | 09:39 |
| *** finn has quit IRC | 09:39 | |
| gitlab-br-bot | buildstream: merge request (juerg/googlecas->master: WIP: Google CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/337 | 09:39 |
| *** finn has joined #buildstream | 09:39 | |
| tristan | project name should probably be changed to 'flatpak-autotools' instead of 'autotools-flatpak', to match the consistent example name everywhere else | 09:39 |
| albfan[m] | tristan: damn it, so cool! It runs under CI too? | 09:41 |
| juergbi | tristan: jonathanmaw needs to load + optionally track elements for workspace reset (for filter redirection !317). Stream._load() is private, though. Wondering what the best API approach is to handle this | 09:42 |
| juergbi | In the current MR he added a thin wrapper 'Stream.load_elements()' that is only used by workspace reset | 09:42 |
| juergbi | A possible alternative would be to make _load() public | 09:42 |
| juergbi | Not sure what makes most sense API-wise | 09:43 |
| *** tristan has quit IRC | 09:44 | |
| juergbi | jonathanmaw: hm, actually, givent hat worksapce_reset() already exists in Stream, another option may be to try to move that into this function as well | 09:45 |
| juergbi | would mean moving the "Workspace does not exist" error into Stream, but would this be an issue? | 09:46 |
| valentind | Has the state "downloadable" disappeared? | 09:46 |
| jonathanmaw | juergbi: AIUI the problem is that then we'd have the interactive prompt "This will remove all your changes, are you sure?" happen first | 09:48 |
| jonathanmaw | when potentially that's being done on a workspace that doesn't exist | 09:48 |
| jonathanmaw | so doesn't make much sense from a user-facing perspective | 09:48 |
| jonathanmaw | and moving the interactive prompt into workspace_reset is trickier, because it currently relies on click | 09:49 |
| juergbi | valentind: yes, we've moved to dynamically pulling. as a side effect we don't know the downloadable state at the beginning of the session anymore | 09:49 |
| juergbi | jonathanmaw: ah, right, I forgot about that | 09:49 |
| toscalix | albfan[m]: good work! | 09:50 |
| juergbi | jonathanmaw: the way it is right now in the MR might be fine, just slightly odd API-wise | 09:51 |
| toscalix | https://blogs.gnome.org/alexl/2018/05/16/introducing-1-8-freedesktop-runtime/ | 09:57 |
| valentind | juergbi, Is it the plan to have "cached" as status when artifact is available on external cache server? | 10:02 |
| juergbi | valentind: no, not before it's downloaded | 10:02 |
| *** aday has quit IRC | 10:12 | |
| *** aday has joined #buildstream | 10:13 | |
| *** aday has quit IRC | 10:15 | |
| *** aday has joined #buildstream | 10:16 | |
| *** dominic has quit IRC | 10:16 | |
| *** aday has quit IRC | 10:19 | |
| *** aday has joined #buildstream | 10:20 | |
| ltu | asking something which has no doubt already been thought of, but if we merge the CAS based artifact cache soon...what happens to the local cache expiry and remote cache expiry branches? | 10:25 |
| *** dominic has joined #buildstream | 10:26 | |
| ltu | will they need considerable re-work in order to land on top of the CAS cahce? | 10:26 |
| ltu | cache* | 10:26 |
| *** dominic has quit IRC | 10:26 | |
| *** dominic has joined #buildstream | 10:26 | |
| gitlab-br-bot | buildstream: merge request (214-filter-workspacing->master: Make workspace commands on a filter element transparently pass through to their build-dependency) #317 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/317 | 10:42 |
| *** dominic has quit IRC | 10:42 | |
| *** ernestask has quit IRC | 10:43 | |
| *** ernestask has joined #buildstream | 10:45 | |
| *** dominic has joined #buildstream | 10:49 | |
| jmac | pytest is skipping all of 'test_compose_include' for me and I don't know why. There are no skipif decorators in the test source. Any ideas how to track this down? | 10:56 |
| juergbi | ltu: some rework will be required. the principal logic can remain but we at least have to move some code around | 10:57 |
| juergbi | ltu: there is also no 'purge' operation yet in CAS but I guess that should fall on me to implement this | 10:58 |
| juergbi | jmac: the integration tests? have you enabled integration tests with --integration? | 10:59 |
| ltu | thanks for the info - will the purge operation affect both of the patches for local and also remote, then? | 10:59 |
| juergbi | ltu: yes, purge is required for any kind of expiry | 10:59 |
| ltu | ok, ta | 11:00 |
| juergbi | we might merge expiry before CAS, not sure | 11:00 |
| jmac | juergbi: Oh yes, that'll be it - thanks | 11:00 |
| gitlab-br-bot | buildstream: merge request (juerg/googlecas->master: WIP: Google CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/337 | 11:01 |
| * tlater likes that we actually have an examples workflow now :) | 11:16 | |
| tlater | finn: This means you'll have to unfortunately move your example from the bst-examples repo into core buildstream, and write a test that executes it | 11:16 |
| tlater | And iirc the plan was for jennis to write an accompanying tutorial | 11:17 |
| tlater | Maybe I should go through that migration process though, and move the entire buildstream-examples repo over in one fell swoop... Comments, tristan? | 11:19 |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 11:21 |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 11:45 |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 11:45 |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 11:47 |
| *** xjuan has joined #buildstream | 12:42 | |
| toscalix | is there a block diagram of buildstream I can take a look at? Or maybe any representation at a high level view of the tool? | 13:39 |
| tlater | toscalix: As far as I am aware, this is the closest we have atm: https://mail.gnome.org/archives/buildstream-list/2018-April/msg00030.html | 13:41 |
| tlater | I might be wrong though | 13:41 |
| toscalix | the diagrams at tristan blog post were done over a year ago. Are they still valid? https://blogs.gnome.org/tvb/2017/02/06/introducing-buildstream-2/ | 13:41 |
| toscalix | ah, thanks | 13:42 |
| toscalix | it seems to me this doc describes more how the tool works but is not a description of BuildStream irself. It is valid though | 13:46 |
| toscalix | s/irself/itself | 13:47 |
| finn | ++ | 13:48 |
| tlater | Ah, sorry, I thought that was what you were looking for. I'm a bit outdated on other descriptions, the readme in the main repository should be a good start to find something though. | 13:48 |
| toscalix | tlater: will go over it | 13:49 |
| gitlab-br-bot | buildstream: merge request (valentindavid/update_mirror->master: WIP: update mirror) #440 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/440 | 13:52 |
| finn | toscalix, are you wanting a simple example to get you going? | 13:52 |
| toscalix | I am in the process of creating a visualization of a roadmap. My idea is to be able to have a common visualization of the ongoing and future work we all understand so we can have a discussion about it at GUADEC. I will use it also to understand and learn. | 13:54 |
| toscalix | to structure the visualization, a common practice is to use themes | 13:54 |
| toscalix | so you group the actions/user stories in themes | 13:54 |
| toscalix | my initial approach is to use the structure of the tool as themes | 13:55 |
| toscalix | the second option is to use activities you with the tool as themes | 13:56 |
| toscalix | ... you do with the tool... | 13:56 |
| tlater | toscalix: Yeah, that may be a bit tricky to find, we don't have many fancy diagrams, unfortunately. | 13:57 |
| toscalix | I assume we will need to create the fancy version. I would be happy with a drawing in a paper :-) | 13:57 |
| tlater | Those are probably littered across individual developer's notebooks ;) juergbi might know about some initial planning documents though. | 13:58 |
| toscalix | the first option is better for early stages of the development while the second option is used with more mature applications | 13:59 |
| toscalix | juergbi: since tristan is on vacation the folliwng days, is it something you can fo for me? | 13:59 |
| toscalix | following | 13:59 |
| toscalix | it would help me a lot to process the tasks/enhancements/features we already have | 14:00 |
| toscalix | and turn them into something easy to understand like a story map | 14:00 |
| juergbi | Tristan recently sent the initial design document to the list https://mail.gnome.org/archives/buildstream-list/2018-April/msg00030.html | 14:02 |
| juergbi | It's definitely not up-to-date but may still be useful | 14:02 |
| *** tiago_ has joined #buildstream | 14:02 | |
| juergbi | toscalix: I can probably help you but I likely won't have time to substantially work on it | 14:02 |
| toscalix | tlater: gave me the link and I checked it but I would need something closer to a block diagram | 14:03 |
| juergbi | My load is higher when tristan is away due to taking over maintenance tasks | 14:03 |
| toscalix | a sketch would be enough, take a pic and send it to me | 14:03 |
| toscalix | juergbi: I understand | 14:03 |
| toscalix | only if you can | 14:03 |
| toscalix | I will manage somehow if you cannot | 14:03 |
| *** tiagogomes has quit IRC | 14:03 | |
| juergbi | I'll see what I can do. Very unlikely this week | 14:06 |
| albfan[m] | toscalix: ;) | 14:12 |
| albfan[m] | Someone ask me about Buildstream on pypi, is it possible? | 14:13 |
| tlater | albfan[m]: Quite hard, since we depend on non-python projects | 14:14 |
| tlater | May be more possible in the future if CAS lands, but I wouldn't bet on it - we're considering switching to a different system (say, meson) anyway | 14:14 |
| tlater | Installation is definitely one of the harder parts to using buildstream atm, hence we supply some handy docker images for that. | 14:15 |
| *** xjuan has quit IRC | 14:23 | |
| paulsherwood | tlater: which non-python projects does it depend on, and are they absolutely necessary? | 14:28 |
| toscalix | juergbi: understood | 14:30 |
| tlater | paulsherwood: Currently ostree and bubblewrap, at least. We're completely ridding ourselves of bubblewrap soon, and I think grpc is a python dependency, so the last remaining non-python dep will be bwrap. | 14:31 |
| gitlab-br-bot | buildstream: issue #399 ("Fails to create build directory for elements with workspaces") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/399 | 14:32 |
| juergbi | tlater: your second bubblewrap should have been ostree | 14:34 |
| juergbi | also, ostree will remain an optional dependency for the source plugin | 14:34 |
| tlater | Oh, whoops, sorry | 14:34 |
| juergbi | while grpcio is on pypi, it's not pure Python | 14:34 |
| tlater | juergbi: In terms of optional dependencies we have a lot more non-python ones, so I think those are fine :) | 14:34 |
| juergbi | we also depend on FUSE | 14:35 |
| juergbi | and in the future likely on an external BuildStream FUSE layer | 14:35 |
| *** xjuan has joined #buildstream | 15:37 | |
| *** dominic has quit IRC | 16:31 | |
| *** toscalix has quit IRC | 16:47 | |
| *** jonathanmaw has quit IRC | 17:01 | |
| gitlab-br-bot | buildstream: merge request (jmac/virtual_directories->master: WIP: Abstract directory class and filesystem-backed implementation) #445 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/445 | 17:06 |
| *** ernestask has quit IRC | 17:47 | |
| *** bethw has quit IRC | 17:52 | |
| cs_shadow | It seems to me like pages are like https://buildstream.gitlab.io/buildstream/elements/junction.html are not mentioned referenced anywhere in the docs or the ToC. Is this by design or is it a bug? (Or am I missing something maybe?) | 17:59 |
| cs_shadow | pages are like -> pages like | 17:59 |
| *** xjuan has quit IRC | 18:03 | |
| *** tristan has joined #buildstream | 18:04 | |
| tristan | juergbi, reading from the irc log, I think that the "Are you sure" can live in the frontend for a non-existing element and crap out later, it's a bit of perfectionism that we try to bail out early | 18:14 |
| tristan | juergbi, also, something I've noticed is that for the workspace commands which *do* load a pipeline, it's unnecessary to resolve element cached state, which might make the load time noticeably faster anyway, reducing the pain of being asked first | 18:15 |
| tristan | I dont like exposing _load() to the frontend, much rather keep that private, and the workspace commands being also in Stream, should be able to use that private method anyway | 18:15 |
| *** xjuan has joined #buildstream | 18:20 | |
| tristan | cs_shadow, they are all referenced from the main "Authoring projects" page: http://buildstream.gitlab.io/buildstream/authoring.html#elements | 18:22 |
| tristan | cs_shadow, but they are still not converted into proper "ToC" elements, so they wont appear properly in the sidebar until that is fixed | 18:22 |
| tristan | I'm still not sure how to actually implement them as ToC elements without completely destroying the helpful manual "flow" of how we layout the section and intersperse links with text | 18:23 |
| cs_shadow | ah! Since they were preformatted like code, I didn't realize they were links. thanks | 18:23 |
| tristan | that is probably part of the first documentation structure :) | 18:24 |
| * tristan very much likes to have a single place to lookup the docs for each individual element or source | 18:24 | |
| juergbi | hm, do we need the testsuite/debian-8 docker image on AArch64? | 19:09 |
| juergbi | grpcio fails there and I'd rather skip debugging that if we anyway don't need the image | 19:10 |
| juergbi | (it works fine on x86-64 and the other AArch64 images based on Debian 9 / Fedora 27) | 19:10 |
| tristan | juergbi, I think that sounds reasonable, we might also consider bumping the python dependency to 3.5 with BuildStream 1.2 | 19:26 |
| juergbi | I would definitely like that. Don't remember the exact reason for not doing this from the start (RHEL, Ubuntu LTS?) and whether that reason is now no longer relevant | 19:28 |
| tristan | Over a year has gone by, when we started, many people didnt have 3.5 yet | 19:29 |
| tristan | (although a good amount of people did, quite a fair amount did not) | 19:29 |
| tristan | Good question though | 19:30 |
| tristan | juergbi, I dont think there was a specific reason other than, quite a noticeable amount of people didnt have 3.5 | 19:31 |
| tristan | But I dont think that's an issue, we could change the dep in master and 1.0 will still be python3.4+ | 19:31 |
| juergbi | Sure, most users are actually on 1.1/master, though, so the distinction is not currently that relevant | 19:36 |
| juergbi | debian stable has 3.5, the last two ubuntu LTS have 3.5/3.6, so it's probably indeed fine | 19:37 |
| juergbi | RHEL doesn't appear to officially support any Python 3, so I assume the minor Python version is not an issue in that case | 19:38 |
| tristan | right, of course a change can only happen in an unstable cycle :) | 19:39 |
| tristan | when we rolled out 1.0, it was shortly after debian 9 became latest stable as I recall | 19:39 |
| tristan | by now, it's quite rare to encounter lack of 3.5 | 19:40 |
| juergbi | makes sense | 19:40 |
| *** tristan has quit IRC | 20:52 | |
| *** cs_shadow has quit IRC | 21:07 | |
| *** xjuan has quit IRC | 21:33 | |
| *** Prince781 has joined #buildstream | 23:30 | |
| *** Prince781 has quit IRC | 23:39 | |
| *** mohan43u has quit IRC | 23:40 | |
| *** mohan43u has joined #buildstream | 23:44 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!