| jjardon | hi, im trying to build the GNOME 3.28.1 release and Im getting this when trying to build: | 00:33 |
|---|---|---|
| jjardon | "[--:--:--][][] WARNING Ignoring redundant source references | 00:33 |
| jjardon | and then the build stops; any idea what is this about? | 00:33 |
| jjardon | using latest buildstream | 00:33 |
| jjardon | full log here: https://paste.gnome.org/pcssrif5d | 00:36 |
| jjardon | seems its beacuse the new ref-storage option | 00:45 |
| jjardon | conversion-to-tarballs changes the ref inline | 00:46 |
| * jjardon uses an older commit | 00:48 | |
| *** tristan_ has joined #buildstream | 04:59 | |
| gitlab-br-bot | buildstream: merge request (jjardon/ci_fedora_27->master: Run test in Fedora27, apart from Debian 8) #378 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/378 | 05:57 |
| gitlab-br-bot | buildstream: issue #356 ("Need to manually specify coverage dependency artifacts") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/356 | 06:00 |
| tristan_ | Who is good a regexes ? | 06:04 |
| *** tristan_ is now known as tristan | 06:05 | |
| tristan | I want to add something like this to our .gitlab-ci.yml: https://docs.gitlab.com/ce/ci/yaml/#coverage | 06:05 |
| tristan | e.g. https://docs.gitlab.com/ce/user/project/pipelines/settings.html#test-coverage-parsing | 06:05 |
| tristan | that would take our already done combined coverage job and bring it into the gitlab UI, would be pretty cool | 06:06 |
| tristan | the job looks like: https://gitlab.com/BuildStream/buildstream/-/jobs/62716737 | 06:06 |
| tristan | and the important line with the overall result looks like "TOTAL 9193 1449 84.24%" | 06:06 |
| * tristan thinks https://docs.gitlab.com/ce/ci/yaml/#coverage is wildly underdocumented | 06:07 | |
| tristan | s/good a regexes/good at regexes/ | 06:07 |
| * tristan personally despises having to write a regex, every, time | 06:08 | |
| juergbi | hm, yes, it doesn't really say how it uses the regex | 06:08 |
| juergbi | based on the 'Test coverage parsing' it essentially uses \1, afaict | 06:09 |
| juergbi | tristan: maybe something like this? TOTAL +\d+ +\d+ \(\d+\.\d+%\) | 06:11 |
| juergbi | missing a + | 06:12 |
| juergbi | TOTAL +\d+ +\d+ +\(\d+\.\d+%\) | 06:12 |
| juergbi | ah, no, match groups in ruby are (), not \(\) | 06:14 |
| juergbi | but then the example doesn't make sense | 06:14 |
| tristan | the example doesnt make huge sense; is it ruby specific even ? | 06:16 |
| * tristan has no clue | 06:16 | |
| tristan | juergbi, does the percent belong inside the group ? | 06:17 |
| juergbi | can only guess | 06:17 |
| * tristan is gonna try a test | 06:17 | |
| tristan | which will take a long time haha | 06:17 |
| juergbi | @project.update_attribute(:build_coverage_regex, /Coverage (\d+)%/) | 06:18 |
| juergbi | that's from the gitlab sources | 06:18 |
| juergbi | based on this I would try | 06:18 |
| juergbi | /TOTAL +\d+ +\d+ +(\d+\.\d+)%/ | 06:19 |
| * tristan tries | 06:20 | |
| tristan | oops | 06:21 |
| tristan | https://gitlab.com/BuildStream/buildstream/pipelines/20433074 | 06:22 |
| tristan | I'm sort of hoping that it will end up in analytics eventually :) | 06:23 |
| tristan | not just "displayed on the pipeline" | 06:23 |
| tristan | would be cool to see a graph of how coverage has improved/regressed over time | 06:24 |
| tristan | juergbi, in light of https://gitlab.com/BuildStream/buildstream/issues/294#note_68188866 ... do you think that https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_artifactcache/ostreecache.py#L105 should be turned into an assert ? | 06:27 |
| tristan | I think that is a bug | 06:27 |
| tristan | not a legitimate error | 06:27 |
| juergbi | as it's used right now, I think so | 06:28 |
| juergbi | with artifact expiry it's no longer so clear cut, though | 06:28 |
| tristan | I think it's still a bug with artifact expiry | 06:29 |
| tristan | then again parallel builds on the same machine could cause it | 06:29 |
| juergbi | exactly | 06:30 |
| tristan | juergbi, with this parallel builds + expiry thing, I'm thinking a good strategy would still be to call it a bug, and hope that it never happens | 06:30 |
| tristan | i.e. once we reach that critical mass where it actually happens, it's justified to actually *fix* it | 06:31 |
| tristan | before that, I'm weary of adding lock files | 06:31 |
| juergbi | yes, as long as the quota is large enough for the working set, it shouldn't happen | 06:31 |
| tristan | well, more than that; the expiry should never expire things from the working set; that is a different bug | 06:32 |
| tristan | it should error out if the working set does not fit on disk, rather than expiring | 06:32 |
| tristan | (or does not fit in the quota, rather) | 06:33 |
| juergbi | I meant working set also across parallel sessions | 06:33 |
| tristan | Ah right | 06:33 |
| tristan | exactly, so; I know it's not *perfect*, but I feel that making it that robust is going too far at this point, so long as we can report decent errors | 06:34 |
| tristan | I guess this would still be a bug, though, hmmm that raises a good question | 06:35 |
| tristan | at this point; it *happened* | 06:35 |
| tristan | which indicates a bug | 06:35 |
| tristan | if it happens because of parallel builds, it might be a worthwhile case to report a human readable error; but it would be nicer if we could really distinguish that between an actual bug | 06:36 |
| tristan | *between that and an actual bug | 06:36 |
| tristan | Interestingly, it seems that `last_successful` already ignores the possibility of a user running `rm -rf ~/.cache/buildstream/artifacts` | 06:38 |
| juergbi | ah, right, that should be handled gracefully | 06:39 |
| juergbi | by considering all files of dependencies changed | 06:39 |
| juergbi | forcing a full rebuild | 06:39 |
| tristan | right, we thought about it for incremental builds | 06:40 |
| tristan | I pointed that out to tlater ... so I suppose the case of `rm -rf` would be handled at the same time | 06:40 |
| tristan | Anything to notice about https://gitlab.com/BuildStream/buildstream/commit/69b0b87508455330f7d74de2864439507664fae4 ? | 06:41 |
| tristan | I dont see any change in the pipeline | 06:41 |
| tristan | https://gitlab.com/BuildStream/buildstream/settings/ci_cd shows an example for pytest-cov | 06:42 |
| tristan | \d+\%\s*$ | 06:43 |
| tristan | I think it's wrong though | 06:45 |
| tristan | it'll risk capturing too much | 06:46 |
| juergbi | these examples are also inconsistent, sometimes % in the matching group, sometimes not | 06:46 |
| juergbi | huge mess | 06:46 |
| * tristan finds it weird that you can set it in the page as well as in the .gitlab-ci.yml | 06:46 | |
| juergbi | yes, was wondering that too | 06:46 |
| tristan | I guess the webpage makes some kind of assumption like, "who would possibly run more than one job !" | 06:47 |
| tristan | but, that's just silly | 06:47 |
| tristan | pipeline status badges | 06:49 |
| tristan | ah, that part is for your README.md | 06:51 |
| tristan | ok, enough time wasted on silly coverage thing, we can still click on the coverage job to get the report, which I often do | 06:59 |
| *** dominic has joined #buildstream | 07:43 | |
| *** jonathanmaw has joined #buildstream | 07:52 | |
| *** valentind has quit IRC | 08:05 | |
| *** toscalix has joined #buildstream | 08:11 | |
| *** dominic has quit IRC | 08:12 | |
| tristan | tlater, for that last comment, I'm going to fix the reference docs for both Element and BuildElement, I'll see if I can get that done in an hour or so | 08:13 |
| tristan | tlater, other than the comments I already made... I think it's looking good for a merge | 08:14 |
| tristan | juergbi, namewise btw, one thing that is regrettable is that the base `BuildElement` defines `configure-commands`; which is quite autotools specific jargon; and we have `Plugin.configure()` which does something else | 08:15 |
| tristan | we're adding `Element.prepare()` to split up the preparation stage from the build stage (where `configure-commands` now land), and Workspace.prepared local state | 08:16 |
| tristan | It would be desirable to deprecate `configure-commands` for `prepare-commands` I think for consistent jargon | 08:16 |
| juergbi | yes, it's not ideal | 08:16 |
| tristan | but, it doesnt seem possible :-S | 08:16 |
| tristan | I wonder if we could alias two variable names | 08:17 |
| juergbi | it's also a trade-off with having duplicated names, which could be confusing | 08:17 |
| *** slaf- has joined #buildstream | 08:17 | |
| juergbi | not sure whether it would really be better in the end | 08:17 |
| *** slaf- has joined #buildstream | 08:17 | |
| tristan | Well, it would certainly be better had we started out with `prepare-commands` | 08:17 |
| tristan | but a change would not be all that great, indeed | 08:18 |
| tristan | juergbi, I'm going to enhance the reference docs such that BuildElement explains what it's doing in the various Element.foo() methods | 08:18 |
| juergbi | sounds good | 08:18 |
| tristan | which should help at least express that configure-commands are run as a part of the prepare stage | 08:18 |
| *** slaf has quit IRC | 08:19 | |
| *** slaf- is now known as slaf | 08:19 | |
| juergbi | tristan: btw: separate prepare() might prevent future command batching between prepare and actual build | 08:19 |
| tristan | and I think another heading at the beginning of `Element()` should be good | 08:19 |
| tristan | juergbi, indeed | 08:19 |
| juergbi | not per se an issue but ideally we can support batching for this | 08:19 |
| tristan | juergbi, well; remote execution is "supposed to be efficient" as you said | 08:19 |
| juergbi | there will always be an overhead | 08:20 |
| juergbi | very difficult to estimate it right now | 08:20 |
| juergbi | will depend on how the workers will be connected to the CAS | 08:20 |
| tristan | maybe we wont have to do the grouping in the end... launching a bwrap sandbox process locally should be a negligible overhead compared to what is being run; but yes, an overhead nonetheless | 08:20 |
| juergbi | that would be ideal, yes | 08:21 |
| tristan | still, if we get incremental builds (workspace or otherwise), the benefit of separating it should outweigh the small invocation overheads | 08:21 |
| tlater | ta tristan, I'll clean out the other problems asap | 08:21 |
| *** noisecell has joined #buildstream | 08:42 | |
| gitlab-br-bot | buildstream: merge request (jmac/artifact-receive-profiling->master: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/383 | 08:53 |
| *** dominic has joined #buildstream | 08:55 | |
| *** aday has joined #buildstream | 08:59 | |
| gitlab-br-bot | buildstream: merge request (issue-21_Caching_build_trees->master: WIP: Issue 21 caching build trees) #372 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/372 | 09:25 |
| *** aday has quit IRC | 09:34 | |
| *** tiago has quit IRC | 09:37 | |
| *** tiago has joined #buildstream | 09:37 | |
| *** aday has joined #buildstream | 09:43 | |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 09:53 |
| tristan | tlater, almost finished an overhaul of plugin author facing documentation... | 10:06 |
| tristan | actually BuildElement was tip of iceburg, we need something consistent; so I've got Plugin/Element/Source all doing the same thing at the top, and just need to fixup BuildElement | 10:07 |
| tristan | that should pave the way for your new prepare() method to have a good place to live in docs | 10:07 |
| tlater | ty :) | 10:10 |
| tlater | Hm, is it worth it to try and reset this: https://gitlab.com/BuildStream/buildstream/merge_requests/386#note_68233724 to Element.prepare(self, sandbox)? | 10:14 |
| tlater | I feel that's almost more confusing | 10:14 |
| tlater | Although if we ever do change the default... | 10:14 |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 10:18 |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 10:18 |
| jjardon | Hi, seems generation of new docker testsuite images are failing; can I have a quick review of https://gitlab.com/BuildStream/buildstream-docker-images/merge_requests/34 , please? | 10:26 |
| gitlab-br-bot | buildstream: merge request (tristan/plugin-authoring-docs->master: enhanced plugin authoring docs) #387 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/387 | 10:37 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 10:39 |
| gitlab-br-bot | buildstream: merge request (Move-_list_dir_contents-to-runcli->master: WIP: Move _list_dir_contents to runcli) #388 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/388 | 10:40 |
| jmac | I'm seeing quite a lot of errors from gitlab ci but I don't think they're docker-related | 10:42 |
| jjardon | jmac: https://gitlab.com/BuildStream/buildstream-docker-images/-/jobs/62795363 | 10:45 |
| jjardon | jmac: or you meant in buildstream pipelines? | 10:46 |
| gitlab-br-bot | buildstream: merge request (issue-21_Caching_build_trees->master: WIP: Issue 21 caching build trees) #372 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/372 | 10:46 |
| jmac | jjardon: In the buildstream pipelines | 10:47 |
| jmac | Yeah, completely different thing | 10:47 |
| jjardon | jmac: oh, sorry then; do you have a link so I can take a look? | 10:48 |
| tlater | jmac: Do you mean the caching issues? I see those all the time as well. | 10:48 |
| gitlab-br-bot | buildstream: merge request (issue-21_Caching_build_trees->master: WIP: Issue 21 caching build trees) #372 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/372 | 10:48 |
| jmac | tlater: They seemed particularly common this morning | 10:49 |
| tlater | This can be entirely down to gitlab infrastructure, though it's been much more common since we switched to the new runner... Probably not a bad idea for jjardon to have a look :) | 10:50 |
| jjardon | tlater: did you switch to a new runner? | 10:51 |
| gitlab-br-bot | buildstream: merge request (tristan/plugin-authoring-docs->master: enhanced plugin authoring docs) #387 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/387 | 10:51 |
| tlater | This happened a while ago, I think you and ssssam[m] were involved in the discussions around that, but it's old memory at this point | 10:51 |
| tristan | jjardon, so I got into a fist fight with gitlab early this afternoon, and even nobody in #gitlab is able to help | 10:51 |
| tristan | jjardon, maybe you have some idea of how we can enable this cool feature that it seems they didnt care about documenting or explaining very well at all | 10:52 |
| tristan | jjardon, check this out: https://docs.gitlab.com/ce/ci/yaml/#coverage | 10:52 |
| tristan | and https://gitlab.com/help/user/project/pipelines/settings#test-coverage-parsing | 10:52 |
| tristan | tlater, rebase and have your docs story straight :) | 10:53 |
| tlater | \o/ | 10:53 |
| jjardon | tlater: jmac please give me a log and I will try to take a look | 10:53 |
| gitlab-br-bot | buildstream: merge request (issue-21_Caching_build_trees->master: WIP: Issue 21 caching build trees) #372 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/372 | 10:53 |
| jjardon | tristan: I will check | 10:53 |
| jmac | I'm not asking you to look at it | 10:53 |
| tristan | tlater, I'll be leaving momentarily... but assuming you've solved those discussions and amended related docs, I'll be ok to merge from handphone on the go | 10:54 |
| tlater | jjardon: I don't think it's anything important, tbh, but you can probably pick out any pipeline. This one, for example: https://gitlab.com/BuildStream/buildstream/-/jobs/62796931 | 10:55 |
| tlater | It will have failures to upload a cache at the end, and a failure to download one at the start | 10:55 |
| jjardon | tlater: cheers, maybe the cache is full, I will check | 10:56 |
| tristan | tlater, before I go, a couple of notes... | 11:03 |
| tristan | tlater, element.py now has a listing of the abstract methods to implement, yours goes under the "build phase", which we now refer to... | 11:03 |
| tristan | for instance Element.get_public_data() most only be called in the "build phase", instead of the "exhaustive list of linked methods we'll absolutely forget to maintain" | 11:04 |
| tristan | tlater, it currently documents them as "must be implemented", you probably want to change that to follow the pattern I layed out in source.py | 11:04 |
| tristan | i.e. "Unless explicitly mentioned, these methods are mandatory to implement." | 11:05 |
| tristan | see Source.init_workspace() in that list... **Optional**: bla bla bla about not implementing it | 11:05 |
| tristan | the wording of everything in the docs is probably not perfect as of yet; that can be improved over time | 11:06 |
| tristan | but getting consistency in *how* we document things is important to keep inline as we move forward | 11:06 |
| * tlater will stick to that, tyvm | 11:07 | |
| tlater | Just started reading into your changes to see exactly what was wrong... | 11:07 |
| tristan | there was even some misinformation :-S | 11:07 |
| * tlater pays far too little heed to documentation, should make sure I don't ignore it | 11:08 | |
| tristan | we were encouraging people to call Element.get_public_data() in the docs for Plugin.preflight(), originally thinking that we could use that to trigger errors at preflight time | 11:08 |
| tristan | and then later telling people you can only call it at assemble time | 11:08 |
| tristan | tlater, I'm also trying to go with a consistent linking pattern to methods | 11:09 |
| tristan | i.e. :func:`Source.stage() <buildstream.source.Source.stage>` | 11:09 |
| tristan | ie better than :func:`~buildstream.source.Source.stage` | 11:09 |
| tristan | which will link to the right thing, but render as an annoyingly ambiguous "stage()" in the HTML | 11:10 |
| tristan | I wasnt able to go through every single file and fix it, though | 11:10 |
| tlater | Ah, that's neat, didn't know we could do that | 11:11 |
| tristan | ideally when jennis is finished with the docs initiative, all of the guidelines are at least layed out | 11:11 |
| tristan | every link can be `Text <link target>`, instead of just `link target` | 11:11 |
| tristan | we use that a lot | 11:11 |
| tristan | for some things it's less important, like say :class:`.SourceError` | 11:12 |
| tristan | in that case it will render exactly the same if we specified :class:`SourceError <buildstream.source.SourceError>` | 11:12 |
| tristan | but when linking methods of classes, it sucks to be ambiguous, you have to actually click the link to know what it's talking about | 11:13 |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 11:14 |
| *** tristan has quit IRC | 11:17 | |
| gitlab-br-bot | buildstream: merge request (issue-21_Caching_build_trees->master: WIP: Issue 21 caching build trees) #372 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/372 | 11:34 |
| *** tristan has joined #buildstream | 11:41 | |
| gitlab-br-bot | buildstream: merge request (issue-21_Caching_build_trees->master: WIP: Issue 21 caching build trees) #372 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/372 | 11:44 |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 11:51 |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 11:54 |
| gitlab-br-bot | buildstream: merge request (issue-21_Caching_build_trees->master: WIP: Issue 21 caching build trees) #372 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/372 | 11:56 |
| gitlab-br-bot | buildstream: merge request (element-prepare->master: Prevent configure commands from running more than once in incremental workspace builds) #386 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/386 | 12:03 |
| tlater | tristan: That should conclude the changes, unless you want me to change some wording/squash the documentation commits | 12:03 |
| *** aday has quit IRC | 12:05 | |
| *** aday has joined #buildstream | 12:07 | |
| *** toscalix has quit IRC | 12:12 | |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 12:52 |
| Nexus | i'm trying to come up with a way of dealing with cached build trees being empty but still being staged into the workspace. An option i thought of was to check if the directory is empty and then send a warning to the user explaining that it is empty and then staging the sources as normal | 12:53 |
| *** valentind has joined #buildstream | 13:24 | |
| *** jsgrant__ has quit IRC | 13:37 | |
| jmac | Do the image-tools or artifact-cache docker images have any automated testing set up? | 14:32 |
| *** toscalix has joined #buildstream | 14:33 | |
| gitlab-br-bot | buildstream: merge request (issue-21_Caching_build_trees->master: WIP: Issue 21 caching build trees) #372 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/372 | 14:40 |
| gitlab-br-bot | buildstream: issue #357 ("Cannot build certain modules after deleting ~/.cache/buildstream") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/357 | 14:52 |
| tlater | jmac: Currently they don't | 14:54 |
| tlater | I don't think any of our docker images do, frankly | 14:54 |
| tlater | The testsuite ones are obviously tested in buildstream CI, but not per-se if for whatever reason we don't run buildstream tests. | 14:55 |
| jmac | Yep. Thought so. | 14:57 |
| jmac | I'm teaching myself docker at the moment so maybe I can add some. | 14:57 |
| tlater | jmac: There's also the fedora image, it would be nice to have something that asserts bst-here works properly; we have quite a lot of few and no tests for it. | 15:03 |
| tlater | s/few/users/ | 15:03 |
| *** noisecell has quit IRC | 15:28 | |
| gitlab-br-bot | buildstream: issue #358 ("Documentation: Element's dependencies order") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/358 | 15:47 |
| gitlab-br-bot | buildstream: merge request (richardmaw/key-summary->master: WIP: List resolved element keys in job summary) #389 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/389 | 16:22 |
| gitlab-br-bot | buildstream: merge request (issue-21_Caching_build_trees->master: WIP: Issue 21 caching build trees) #372 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/372 | 16:37 |
| *** jonathanmaw has quit IRC | 16:37 | |
| *** dominic has quit IRC | 17:01 | |
| gitlab-br-bot | buildstream: merge request (jjardon/order_elements->master: source/format.rst: Order of components in "elements:" doesn't matter) #390 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/390 | 17:55 |
| gitlab-br-bot | buildstream: merge request (jjardon/order_elements->master: source/format.rst: Order of components in "elements:" doesn't matter) #390 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/390 | 17:57 |
| *** toscalix has quit IRC | 18:44 | |
| *** aday has quit IRC | 19:01 | |
| *** aday has joined #buildstream | 19:01 | |
| *** aday has quit IRC | 19:05 | |
| *** aday has joined #buildstream | 19:06 | |
| valentind | It would be nice to import _downloadablefilesource.py in custom plugins. But it does not seem easy to import because of the plugin system. Anybody has any trick to import it? | 19:16 |
| *** aday has quit IRC | 19:21 | |
| *** aday has joined #buildstream | 19:22 | |
| *** aday has quit IRC | 19:22 | |
| *** jsgrant has quit IRC | 19:23 | |
| *** jsgrant has joined #buildstream | 19:24 | |
| *** jsgrant has quit IRC | 19:28 | |
| *** jsgrant has joined #buildstream | 19:28 | |
| *** Prince781 has joined #buildstream | 21:37 | |
| *** tristan has quit IRC | 22:22 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!