| *** Prince781 has quit IRC | 01:18 | |
| *** Prince781 has joined #buildstream | 02:30 | |
| *** Prince781 has quit IRC | 03:28 | |
| *** tristan has quit IRC | 04:23 | |
| *** tristan has joined #buildstream | 04:28 | |
| *** Prince781 has joined #buildstream | 04:50 | |
| *** Prince781 has quit IRC | 04:54 | |
| *** jsgrant has quit IRC | 04:56 | |
| *** Prince781 has joined #buildstream | 05:25 | |
| *** Prince781 has quit IRC | 05:49 | |
| *** toscalix has joined #buildstream | 07:30 | |
| *** bochecha_ has quit IRC | 07:43 | |
| *** bochecha_ has joined #buildstream | 07:47 | |
| *** jennis has joined #buildstream | 08:04 | |
| paulsherwood | please can we fix the initial text at https://wiki.gnome.org/Projects/BuildStream to match the text at https://gitlab.com/BuildStream/buildstream/blob/master/README.rst ? | 08:16 |
|---|---|---|
| * paulsherwood has just had earache from a colleague complaining about the gnome text (which is the first thing google will offer) | 08:17 | |
| tristan | paulsherwood, done | 08:21 |
| *** bethw has joined #buildstream | 08:23 | |
| toscalix | paulsherwood: I will put effort on the front page/product charter. | 08:23 |
| paulsherwood | tvm | 08:24 |
| toscalix | For those of you who do not know me, btw, I will be helping tristan on buildstream. You will see a mail on the mailing list later today about it. | 08:26 |
| toscalix | I work at Codethink as consultant. This is not my first collaboration with GNOME. I am new to Buildstream though so it will take me some time to get into details | 08:29 |
| *** jonathanmaw has joined #buildstream | 08:38 | |
| paulsherwood | toscalix: welcome aboard :) | 08:41 |
| *** solid_black has joined #buildstream | 08:41 | |
| toscalix | thanks | 08:41 |
| tristan | welcome toscalix :D | 08:42 |
| toscalix | I will attend to today's IRC monthly meeting | 08:43 |
| tlater | toscalix: It's still early enough that time zones probably aren't messing with me here, did the meeting date change? | 08:50 |
| toscalix | the IRC meeting is tomorrow, sorry | 08:52 |
| toscalix | and now that I think about it, it is bank holiday in many countries | 08:52 |
| tristan | Hmmm | 08:52 |
| tristan | Should we try to punt it ? it's a bit late for this | 08:52 |
| tristan | Maybe we should reschedule the holiday instead ? | 08:52 |
| tlater | Yep, that sounds preferable | 08:53 |
| tlater | Move it to a day around Christmas? | 08:53 |
| toscalix | let's see what laurence thinks about moving it | 08:54 |
| tristan | I think it would be good to bump it by a week | 08:55 |
| tristan | next tuesday | 08:55 |
| tristan | in fact, the majority of the attendees are in the UK | 08:56 |
| tristan | So I think it makes sense | 08:56 |
| *** dominic has joined #buildstream | 09:00 | |
| tlater | tristan: Tomorrow is not a bank holiday in the UK :) | 09:01 |
| tristan | I am confused | 09:01 |
| tristan | Why do people think it's a holiday ? | 09:01 |
| *** tiago has quit IRC | 09:01 | |
| *** solid_black has quit IRC | 09:01 | |
| tristan | You know, since I dont work at a bank, I really don't know these things in advance | 09:01 |
| tlater | It's in a lot of other countries, not the UK, as far as I am aware | 09:01 |
| *** tiago has joined #buildstream | 09:02 | |
| *** solid_black has joined #buildstream | 09:02 | |
| gitlab-br-bot | buildstream: merge request (juerg/push-duplicate->master: Push improvements) #442 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/442 | 09:07 |
| toscalix | ah, not in UK, true | 09:08 |
| milloni | is the first monday of may a bank holiday in the uk? | 09:25 |
| milloni | if so people might get confused cause this monday is the 30th | 09:25 |
| toscalix | milloni: it is | 09:28 |
| toscalix | that was my confusion too. | 09:28 |
| tlater | Hm, usually not following the international norm is weird, but I suppose it's handier to have a long weekend than a random day off | 09:29 |
| tristan | jonathanmaw, juergbi eek.... ummm... was it necessary to change the initialization process for redirection of workspace commands ? | 09:50 |
| tristan | Actually, this is in flux, all of that changed code is gone in my branch which aims to sort out this pipeline mess | 09:50 |
| tristan | So, I expect I'll have to look closely at what that patch does and factor it in | 09:51 |
| jonathanmaw | tristan: I think we can avoid doing that if we partially initialize the app once, then fully initialize it again later | 09:53 |
| jonathanmaw | but that sounds like it could have unintended consequences | 09:53 |
| *** cs_shadow has joined #buildstream | 09:54 | |
| Nexus | tristan: please could you expand on what you said in your reply to my email about "just address what we want to download separately" I can't quite follow what you mean | 09:54 |
| tristan | Nexus, artifacts are named blobs, which we transfer to and fro; they are addressed by their artifact name, which is composed of a project name, element name and cache key | 09:55 |
| tristan | Nexus, it is not possible to tell the artifact server "Give me this part of that blob" | 09:56 |
| tristan | Instead, we need to address the blobs separately | 09:56 |
| tristan | With ostree this means making separate commits for those blobs | 09:56 |
| tristan | As Sander points out, there will/may be a different way to do that with CAS | 09:56 |
| tristan | But that should be a separate thing, because CAS should still support separated naming of blobs (as it must support addressing of artifacts anyway) | 09:57 |
| tristan | And I dont want to block things because it might be more elegant to do it a different way with CAS | 09:57 |
| tristan | Rather, we can change that once we have CAS | 09:58 |
| tristan | jonathanmaw, So just to paint a picture (I have meeting in few minutes...) App.initialize() now just creates the Stream object and some basic things, it no longer create the Pipeline at all, and partially_initialized() is not needed anymore | 09:59 |
| tristan | jonathanmaw, all pipeline manipulation stuff has moved to Stream.build(), Stream.fetch(), Stream.track() etc | 10:00 |
| tristan | So the Stream() is the main core frontend facing API and does the highlevel core business logic, while Pipeline is only for loading and manipulating lists of elements | 10:00 |
| laurence | toscalix, I don't think we need to move tomorrow's meeting. vast majority of regular attendees are in the UK. exceptions being juergbi, tristan and yourself, who are all expected to turn up | 10:17 |
| jonathanmaw | tristan: ok, do you think your tristan/pipeline-refactor branch is stable enough that I can try and adapt my changes to that branch, or should I wait until it's merged into master? | 10:18 |
| *** solid_black has quit IRC | 10:18 | |
| jennis | Is there any reason / has there ever been a discussion as to why we favour os.path to pathlib.Path? | 10:30 |
| * jennis stumbled across pathlib.Path this weekend and is curious | 10:30 | |
| tlater | jennis: You'd have to use pathlib.Path throughout the entire code base to gain any advantage | 10:31 |
| tlater | I find trying to use it adds a *bit* too much boilerplate still | 10:31 |
| jennis | ahh, I guess we're in too deep for that | 10:32 |
| * skullman tried it out when it was announced and had issues with its unicode handling, but they may have been fixed | 10:32 | |
| tlater | jennis: We do use it occasionally for `.parents` - I don't think there is an os.* equivalent for that. | 10:33 |
| tristan | jonathanmaw, My next push to it will make the biggest change... tests are *almost* all passing | 10:33 |
| tristan | jonathanmaw, Not sure if it answers your question, so I'll share a bit my plan... | 10:34 |
| jennis | tlater, oh really? Guess I'm not grepping properly then... | 10:34 |
| tristan | jonathanmaw, basically; I've done all the restructuring so that Pipeline is internal and owned/used by Stream... I still need to do the actual refactoring of Pipeline *itself* | 10:35 |
| tristan | jonathanmaw, and besides this, I'm also going to hide the scheduler from the frontend behind Stream(), such that the frontend really only sees Context, Project and Stream | 10:35 |
| tristan | I've also discovered that, miraculously enough, `bst source-bundle` seems to "still work" | 10:39 |
| * tlater clearly wrote very high quality code there | 10:40 | |
| tristan | jennis, tlater I agree it adds boiler plate, although I think we use pathlib for heavy lifting, for implementation of utils.glob() (or we did use it initially, maybe it changed for a straight regex) | 10:40 |
| tristan | But... one thing to take into account | 10:40 |
| tristan | jennis, tlater ... and I suspect this might bite us one day... if we get to supporting many platforms, we get it wrong in quite a few places | 10:41 |
| tlater | Yep... Part of preparing bst to run on, say, Windows, would probably be to start using pathlib... | 10:42 |
| tristan | I.e., we use os.path.join() for loading anything on the host, that is correct... *however*, we should not be making assumptions that host `os.path.join()` is correct for constructing strings which might be used in the sandbox | 10:42 |
| jennis | tristan, yes the impression I got was that pathlib.Path is much more favourable to use as it works well cross-platform | 10:42 |
| tristan | os.path.join() should be fine on windows | 10:42 |
| tristan | but maybe not everything, not sure... | 10:42 |
| tlater | tristan: I think we have other, bigger problems for windows adoption, though | 10:43 |
| tristan | anyway, windows is a long shot... although it would be really fun to get the source code for the MSVC compiler and base C runtime and kernel there, and bootstrap the next big version of windows with BuildStream :D | 10:43 |
| tlater | tristan: On that note, docker would make for an interesting sandbox implementation | 10:44 |
| tristan | the real utility of running natively on windows I think is still for building linux embedded on windows machines | 10:45 |
| tristan | And I think the WSL or whatever it's called thing that is available since windows 10 will mostly allow that | 10:46 |
| tristan | so we could have a sandbox for that, not sure if docker is the right way to do that, maybe it is | 10:46 |
| tlater | Hm, interesting thought, I wonder if the "WSL" has some form of an API? | 10:47 |
| * tlater doubts it, but *maybe* | 10:47 | |
| tristan | yeah it should, juergbi looked into that a while back I'm pretty sure it does | 10:47 |
| tristan | tlater, we only hear about "It supports Ubuntu" or something high level market speak | 10:48 |
| tristan | And probably it's hidden underneath a crap ton of user friendly point and click annoyances | 10:48 |
| tlater | I assumed it would mostly be end-user facing, so I figure it might be hard to use for any real programming | 10:49 |
| tristan | but I would totally expect that somewhere beneath that whole mess, is an actual API :) | 10:49 |
| tristan | I would want to use it directly, and stage only runtimes we import and build with BuildStream | 10:49 |
| tristan | and not have to "Run BuildStream in Ubuntu in Windows" or something redundant like that | 10:49 |
| tristan | tlater, it's mostly just a question about how limited the implemented syscall interface is, iirc, but it must be fairly well implemented for it to run ubuntu | 10:50 |
| tristan | maybe we would not have user namespaces though :) | 10:50 |
| * tlater is really curious about this :) | 10:51 | |
| tlater | Though docker might still be a better idea, given that it would allow mac support as well. | 10:51 |
| tristan | tlater, an interesting breakage I noticed while looking at the pipeline refactor: `bst fetch --track --except` is totally broken :) | 10:57 |
| tristan | it probably never worked as advertised, actually | 10:58 |
| tlater | Erk | 10:58 |
| gitlab-br-bot | buildstream: merge request (juerg/push-duplicate->master: Push improvements) #442 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/442 | 10:58 |
| gitlab-br-bot | buildstream: issue #325 ("bst is pushing artifact it just have pulled") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/325 | 11:08 |
| gitlab-br-bot | buildstream: merge request (juerg/push-duplicate->master: Push improvements) #442 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/442 | 11:08 |
| tristan | jonathanmaw, I've pushed the bigger change now, it's being tested here: https://gitlab.com/BuildStream/buildstream/pipelines/21290000 | 11:16 |
| tristan | jonathanmaw, you might look and see | 11:16 |
| tristan | As I said, I still have to untangle the Pipeline(), it's still using the same weird initialization paths, but now the damage is localized | 11:17 |
| tristan | Also I still mean to change a bunch of subtle stuff, like hiding the Scheduler away and making that a private detail of Stream | 11:17 |
| tristan | I also still didnt remove the now pointless App.partially_initialized() | 11:18 |
| jjardon | https://gitlab.com/BuildStream/buildstream/issues/325 \o/ thanks a lot juergbi ! | 11:20 |
| tristan | jonathanmaw, On a separate topic, ... valentind is working on the `bst mirror` stuff while as I understand you will be getting back to the client side of source mirroring, you will probably both want to sync up at some point | 11:23 |
| jonathanmaw | tristan: yep | 11:23 |
| tristan | I've suggested using the mailing list for now, as we're at the beginning and probably ironing out kinks in the architecture | 11:24 |
| valentind | jonathanmaw. Yes. Paths for mirror generated by "bst mirror" should be generated by plugin. And we need a support of incremental namespacing. | 11:24 |
| * tristan now understands what valentind was talking about with the word "namespaces" :) | 11:25 | |
| valentind | Sorry tristan, I thought you used that term. | 11:26 |
| tristan | valentind, Oh maybe :) no worry ! | 11:40 |
| tristan | valentind, I just remember being confused last week, cause namespaces can mean a lot of things :) | 11:41 |
| valentind | tristan, yes. | 11:41 |
| valentind | jonathanmaw, I sent an email on the mailing list about that. | 11:57 |
| jennis | Hey guys, has anyone got a chance to review !421 expiring the remote share? I think it's only 1 commit away from ready. Regarding the last commit, it's WIP I'd be grateful for some help? | 12:57 |
| jennis | *and I'd | 12:57 |
| tristan | jennis, I was tied up last couple days deep in refactor... and haven't looked yet because I'm hoping for juergbi to land the scheduling changes ahead of that (as you probably noticed in issue comments) | 13:02 |
| jennis | tristan, yes I did. No worries. I'd just like to get this "artifact too large" case dealt with as it's infuriating me | 13:05 |
| jennis | Any idea when those scheduling changes are likely to land? juergbi? | 13:06 |
| juergbi | jennis: hopefully really soon | 13:15 |
| jennis | nice | 13:17 |
| juergbi | tristan: in case you haven't realized, you're accessing private pipeline API in _stream.py | 13:41 |
| Nexus | I need to understand more about remote artifact caches, who's the best person for me to talk to | 13:42 |
| tristan | juergbi, there are some loose ends | 13:43 |
| tristan | juergbi, it's not ready for review :D | 13:43 |
| juergbi | yes, I figured. just thought I mention it | 13:43 |
| tristan | juergbi, I am also doing something disgusting from app.py, I needed to tape a couple things in place whilst moving the underlying machinery :) | 13:43 |
| tristan | _pipeline.py is going to change almost completely, and a nice API will emerge, but a ton of things needed to happen for that to even be possible | 13:44 |
| juergbi | right. it's a bit of a conflict area with my changes, let's hope it won't be too bad | 13:45 |
| tristan | Its the high level initialization, which changes almost completely; the frontend will have a very limited view of the core | 13:46 |
| juergbi | Nexus: just ask in here and I or someone else will try to answer | 13:46 |
| tristan | All of those arguments to app.initialized() have disappeared | 13:46 |
| tristan | and finally I removed fetch_subprojects from Context too | 13:46 |
| Nexus | juergbi: generally, i know nothing about that similatities or differencesm so i need to ask everything | 13:47 |
| tristan | juergbi, which changes in particular ? to be honest; while I doubt a magic git rebase merge would have any chance of success - I am confident that applying whatever changes you have to the new core will be straight forward | 13:48 |
| juergbi | tristan: the more dynamic handling of build dependencies | 13:48 |
| tristan | Ah, that requires frontend initialization specifications ? | 13:48 |
| tristan | I dont think it would much | 13:48 |
| juergbi | no, it's more core pipeline stuff | 13:49 |
| juergbi | so it might not be too bad | 13:49 |
| tristan | Ah, yeah; some things there will change; the Element stuff remains untouched, or almost completely untouched | 13:49 |
| tristan | I doubt it will be bad | 13:49 |
| tristan | Whatever changes you made to _pipeline.py will have to be re-applied manually | 13:50 |
| jennis | Nexus, the remote cache is almost identical to ~/.cache/buildstream/artifacts/ostree/ | 13:50 |
| tristan | unfortunately that was the last part, though; so you will have to wait until tomorrow to see the brave new world :) | 13:50 |
| juergbi | hehe | 13:51 |
| jennis | On the server, this will be within /data/artifacts | 13:51 |
| tristan | I am essentially thinking, the pipeline will do loading in one stage, without knowledge of what the target lists are for... and Stream will feed those targets back into functions which do exotic sorting and filterings, and those results will get fed into the Queues and the scheduler | 13:52 |
| tristan | And the artifact cache initializations will be removed from Pipeline as well | 13:52 |
| jennis | When you set up a server, we instruct whoever is doing this to create a user, aptly named "artifacts" who has write permissions for this directory | 13:52 |
| * tristan misstepped and did that prematurely, then realized that artifact cache initialization needs to happen *in between* | 13:52 | |
| tristan | probably, your branch will end up removing a lot of that | 13:53 |
| tristan | although loading the configs still needs to be done, after recursive loading, such that the recursive project configurations are already present | 13:53 |
| jennis | One thing I found the other day was that, although these cache's look identical, the disk space taken up by the local cache is more. tristan informed me that this was due to sending compressed objects to the server | 13:54 |
| tristan | jennis, due to using archive-z2 repo mode on the server, yes | 13:55 |
| jennis | Nexus ^^ which we do upon initialising the remote cache: `ostree init --mode archive-z2 --repo artifacts` | 13:56 |
| jennis | Also note that there is no tarcache on the server | 13:58 |
| *** tristan has quit IRC | 13:58 | |
| laurence | I've sent a mail to the list to update on the role of toscalix | 14:01 |
| toscalix | thank you laurence I will answer it with info about where I plan to help | 14:02 |
| *** tristan has joined #buildstream | 14:03 | |
| laurence | great :) | 14:03 |
| jjardon | Are the different "format-version" documented somewhere? | 14:37 |
| toscalix | laurence: done | 14:38 |
| toscalix | I hope to get feedback | 14:38 |
| juergbi | jjardon: there are 'since format version' notes in the documentation for the corresponding config keys | 14:39 |
| jjardon | juergbi: thanks; is that in the docs somewhere? seems it's only mentioned here as the default paramter: https://buildstream.gitlab.io/buildstream/projectconf.html#builtin-defaults | 14:43 |
| jjardon | btw, does current buildstream defaults to "format-version: 0" ? | 14:43 |
| juergbi | jjardon: an example is at the end of https://buildstream.gitlab.io/buildstream/projectconf.html#ref-storage | 14:43 |
| jjardon | ah! here it is: https://buildstream.gitlab.io/buildstream/projectconf.html#format-version | 14:44 |
| juergbi | yes, default is version 0 as per your previous link with the defaults | 14:44 |
| *** persia has quit IRC | 15:03 | |
| jjardon | juergbi: is ok if I open an issue to document the differences between versions, so it's easy to see why I should use a different format-version? (I think the latest is 9) | 15:06 |
| *** oknf[m] has joined #buildstream | 15:06 | |
| jjardon | laurence: adds68 valentind https://cache.sdk.freedesktop.org/releases/refs/heads/runtime/org.freedesktop.Sdk/arm/ | 15:15 |
| jjardon | tristan: ^ (thanks for that sled-8) | 15:16 |
| valentind | jjardon, great! | 15:16 |
| valentind | Let me try it. | 15:16 |
| adds68 | woohoo \o/ | 15:16 |
| jjardon | oops, wrong channel, sorry still related tough :) | 15:16 |
| tristan | jjardon, I was thinking such a doc could be useful, but should link directly to the features for each introduced "thing", note there will be some gaps (versions which were bumped because of a change in functionality of a feature during unstable cycle) | 15:17 |
| jjardon | valentind: cheers, please open an issue if you see something wrong | 15:18 |
| tristan | jjardon, currently though, the reverse is completely documented; i.e. every YAML configuration which is not available in version 0, states it's version | 15:18 |
| tristan | if it is not, that is a bug, but I am pretty sure that anything which introduced a version bump, states the version | 15:19 |
| *** bethw has quit IRC | 15:20 | |
| jjardon | tristan: mmm, I tihnk state the version in a buildstream project is not the same as the version itself being documented? | 15:20 |
| tristan | jjardon, it's more important I think, i.e. think of it this way: You look at the reference to find how to use features, the reference tells you if a documented feature is only available in a specific version | 15:21 |
| tristan | jjardon, however as I said, such a doc which does the reverse could also be useful | 15:21 |
| tristan | i.e. an ordered list which links out to the specific features introduced with each version | 15:21 |
| tristan | which (as I also mentioned above), may have gaps | 15:21 |
| jjardon | yup, but still would be better than nothing I think; let me open an issue so we do not forget. | 15:22 |
| gitlab-br-bot | buildstream: issue #381 ("Introduce a new source plugin - `SourceTransform`") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/381 | 15:22 |
| tristan | jjardon, the fact there is a version itself, is actually one of the *first* things documented: http://buildstream.gitlab.io/buildstream/projectconf.html#format-version | 15:23 |
| tristan | jjardon, and every feature which requires a version links to that link, with "Available since format version X" text | 15:23 |
| *** bochecha_ has quit IRC | 15:23 | |
| jjardon | tristan: tristan that doesnt give me any info why a bst project is using version 3 , 4 or 9. Or why I should upgrade to a new version with new features that can be useful to my project | 15:24 |
| tristan | jjardon, Why would you want to know that, though ? | 15:24 |
| tristan | jjardon, as I said, it *can* be interesting, I'm not against having a page which has an incremental list documenting that, and have thought it could be useful in some way | 15:25 |
| tristan | I.e. if a bst project requires version 3, it is not really up to you to wonder why: it's up to you to upgrade bst and get a bst which supports it | 15:26 |
| tristan | jjardon, if you are on the other hand, adding a feature to an existing project: It's up to you to read the reference about that feature and also update the format-version | 15:26 |
| tristan | for that part, we have it covered | 15:26 |
| juergbi | tristan: maybe an overview of which BuildStream version supports which format version would be useful, though | 15:28 |
| juergbi | to know the bst requirement for a project | 15:28 |
| tristan | juergbi, yes, as I've stated a couple of times above, I'm certainly not against it :) | 15:29 |
| tristan | It should ideally indicate at least the major point stable release it was introduced in as well | 15:29 |
| jjardon | I see. Still a after quick "$ git grep "since :ref:"" only versions 1,4,6,8 are mentioned at all ; no features have been added in any other versions? | 15:30 |
| *** Prince781 has joined #buildstream | 15:30 | |
| tristan | for each version... maybe a treeish list starting with 1.2 (because 1.0 iirc came out with version 0).. and all the versions introduced in 1.2... then in next cycle 1.3, we start adding to the list of 1.4 features | 15:31 |
| tristan | something like that | 15:31 |
| tristan | jjardon, I mentioned above there is a reason for there being "gaps" | 15:31 |
| tristan | "note there will be some gaps (versions which were bumped because of a change in functionality of a feature during unstable cycle)" | 15:31 |
| tristan | jjardon, one of the reasons for that is for instance, we now require version 8 for "ref-storage" (the project.refs feature) | 15:32 |
| jjardon | tristan: yeah, Im asking now if that is actually the case for all the versions not mentioned there. Or we simply don't know | 15:32 |
| tristan | jjardon, it was introduced in a different version, but now we store the junction.refs separately, so we use version 8 to indicate that feature | 15:32 |
| tristan | it happened in a few cases | 15:32 |
| tristan | I cant say with 1000% certainty but I've taken very good care to document those | 15:33 |
| gitlab-br-bot | buildstream: issue #382 ("Document changes in format-version in a central place") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/382 | 15:36 |
| tristan | Nicely named issue :) | 15:37 |
| *** Prince781_ has joined #buildstream | 15:38 | |
| tristan | lets link to it from http://buildstream.gitlab.io/buildstream/projectconf.html#format-version, but put it somewhere at the end of the reference ToC | 15:38 |
| *** Prince781 has quit IRC | 15:39 | |
| *** Prince781_ is now known as Prince781 | 15:39 | |
| * tlater is successfully calculating cache sizes on a separate thread/process/asyncio-thing :) | 16:17 | |
| skullman | neat | 16:18 |
| tlater | skullman: I think the interface is pretty close to what it will look like... I should push and link you to my MR now, sorry, I had a few meetings in-between and forgot. | 16:19 |
| * tlater should have something pop up his todo list every hour or so | 16:20 | |
| 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 | 16:25 |
| tlater | skullman: That's the one :) https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 16:26 |
| skullman | ta | 16:26 |
| 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 | 16:28 |
| *** Prince781 has quit IRC | 16:48 | |
| *** toscalix has quit IRC | 17:00 | |
| *** dominic has quit IRC | 17:12 | |
| *** jonathanmaw has quit IRC | 17:32 | |
| *** jonathanmaw has joined #buildstream | 18:00 | |
| *** slaf has joined #buildstream | 18:55 | |
| *** tristan has quit IRC | 20:12 | |
| *** Prince781 has joined #buildstream | 23:27 | |
| *** jsgrant has joined #buildstream | 23:42 | |
| *** Prince781 has quit IRC | 23:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!