| tristan | valentind, it's a breaking change, I don't think anyone had it in mind to backport it | 04:08 |
|---|---|---|
| tristan | valentind, it replaces junction name coalescing, and is unfinished since it completely disallows multiple junctions to the same project | 04:09 |
| tristan | I think that you can still achieve whatever you need without this though, just with less error protections | 04:09 |
| tristan | i.e. you can still achieve the overrides with junction name coalescing | 04:10 |
| tristan | valentind, !1913 looks out of the blue to me, fwiw I think that that is not really a problem space that is specific to junctions | 04:16 |
| tristan | if you had everything in a single project, you will still find areas where projects have cyclic dependencies; for example you normally would depend on an early build of busybox, but at later stages you would want to *replace* that with coreutils and bash | 04:17 |
| tristan | so it becomes desirable to swap out the overlapping busybox with later reverse dependencies | 04:18 |
| *** tristan has quit IRC | 04:41 | |
| *** narispo has quit IRC | 05:00 | |
| *** narispo has joined #buildstream | 05:00 | |
| *** aminbegood has joined #buildstream | 06:20 | |
| *** benschubert has joined #buildstream | 07:02 | |
| *** aminbegood has quit IRC | 07:10 | |
| *** phildawson has joined #buildstream | 07:45 | |
| *** jude has joined #buildstream | 07:48 | |
| *** pointswaves has joined #buildstream | 07:52 | |
| *** pointswaves has quit IRC | 07:55 | |
| *** seanborg has joined #buildstream | 08:04 | |
| *** rdale has joined #buildstream | 08:17 | |
| coldtom | the issue isn't cyclic dependencies aiui, it's any time you want to use something from a junction but modify the build somehow | 08:18 |
| coldtom | sure you can patch the junction, or use an overlay, but these both feel hacky and like you're doing something kinda wrong | 08:18 |
| *** tpollard has joined #buildstream | 08:20 | |
| *** seanborg has quit IRC | 08:22 | |
| *** seanborg has joined #buildstream | 08:22 | |
| *** seanborg has quit IRC | 08:23 | |
| *** seanborg has joined #buildstream | 08:23 | |
| *** santi has joined #buildstream | 08:30 | |
| juergbi | coldtom: I think we need to distinguish the different use cases | 08:34 |
| benschubert | coldtom: not sure why a `patch` would be hacky there? It's a well known and used practice: Archlinux, Debian, Ubuntu, Fedora, they all use patches on top of their sources, usually using `quilt` | 08:34 |
| *** aminbegood has joined #buildstream | 08:36 | |
| benschubert | (the `patch` has the advantage of being an explicit well recognized mechanism :) ) | 08:36 |
| juergbi | I'd rather tend towards git branches | 08:37 |
| juergbi | but that's mostly a matter of personal preference | 08:37 |
| coldtom | benschubert, they patch their sources, but i don't really see junctions as the same as a regular source - it's more a metasource to me, and so it feels very different to patch it | 08:37 |
| juergbi | and what's more convenient depends on how frequently changes are applied upstream/downstream | 08:37 |
| benschubert | juergbi: true. I tend to prefer `quilt` as I find it easier to grasp the exact changes done | 08:38 |
| WSalmon | buildstream2 pulls from the bottom of the tree rather than the top of the tree, AFAICT it dose not skip build deps of my build deps and this coupled with bst not ciurciting pushes for artifacts on the server, means that some of my jobs on runners that do not always have a hot cache are taking a hug amount of time, it also means that developrs have to have to down load a lot more than they need, am I missing something? I used to have CI stages that | 08:40 |
| WSalmon | would `bst build` then `bst checkout` if the cache server was up but the local cache was cold they would download one thing and then check it out, currently they have to download and upload 100s of things.. | 08:40 |
| juergbi | WSalmon: bst build should not be pulling build-only dependencies by default, unless they are needed in the current session | 08:41 |
| juergbi | if you see this happening, this sounds like a bug. however, I think we already have this covered by tests | 08:42 |
| juergbi | and bst artifact checkout should only pull the dependencies as per --deps option. default is --deps run, though, not --deps none | 08:46 |
| juergbi | build-only dependencies should not be pulled unless --deps build or --deps all is specified | 08:46 |
| WSalmon | but i need to run bst build for the rare cases when the last one or two elements have been expired cos i havent used that branch for a while.. | 08:48 |
| juergbi | as I mentioned, bst build should not be pulling unneeded build-only dependencies either by default | 08:48 |
| juergbi | if you see this happening, a test case would be ideal | 08:48 |
| WSalmon | ok, i dont really understand how it can know what it needs when it pulls from the bottom up | 08:49 |
| juergbi | internally it starts top down | 08:50 |
| WSalmon | i will investigate the case were it looks like its pulling build deps of build deps | 08:50 |
| juergbi | however, it determines fairly early which build dependencies are definitely needed | 08:50 |
| juergbi | and it prioritizes those from the bottom of the stack as they are needed first | 08:50 |
| cphang | WSalmon could you link to CI jobs that show this occurring? | 08:52 |
| *** mohan43u_ has joined #buildstream | 08:54 | |
| juergbi | WSalmon: hm, maybe we actually optimize build-only dependencies away only based on the local cache | 08:55 |
| *** mohan43u has quit IRC | 08:55 | |
| juergbi | so if nothing is local yet we would always pull all elements | 08:55 |
| benschubert | juergbi: I *think* it's the case yes | 08:55 |
| juergbi | that would definitely sound like an area that we could improve | 08:56 |
| benschubert | fixing that is not a trivial change in the pipeline though (need to be able to dynamically add stuff, which it was not really made to do). | 08:56 |
| benschubert | +1 on fixing that and make the pipeline really push-based :) | 08:56 |
| *** mohan43u_ has quit IRC | 08:56 | |
| *** mohan43u has joined #buildstream | 08:57 | |
| juergbi | I thought we already made it more dynamic than that a long time ago but I'm probably mixing something up | 08:57 |
| WSalmon | cphang, im going to double check but i think the bootstrap stuff is build-dep of a build-dep of the targets for https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/546340519 but im not 100% and im not 100% that there is enough in the cache so i was going to check. but from what benschubert and juergbi are saying then it sounds like that is whats happening | 08:58 |
| *** tristan has joined #buildstream | 08:59 | |
| *** chipb_ has joined #buildstream | 09:00 | |
| *** chipb has quit IRC | 09:00 | |
| juergbi | tristan: junctions mail, last paragraph, I'm a bit confused by "we might have both of these appraoches". do you mean "might need/want"? | 09:01 |
| *** ChanServ sets mode: +o tristan | 09:03 | |
| tristan | juergbi, yes. | 09:03 |
| benschubert | tristan: let me know when you have a few brain cycles free to discuss cache key tests :) | 09:03 |
| juergbi | benschubert: https://gitlab.com/BuildStream/buildstream/-/merge_requests/1718 removed the set_required logic | 09:04 |
| juergbi | didn't this cause the regression noticed by WSalmon? | 09:04 |
| tristan | benschubert, brain cycles I have, I expect to be interrupted very soon though | 09:05 |
| benschubert | juergbi: https://gitlab.com/BuildStream/buildstream/-/merge_requests/1718/diffs#11743b796594142e47df22054b99d263d52e28aa_1625_1559 should have been safe. AFAIK we did have this problem for longer than that. Might want to try though if it indeed was a regression | 09:06 |
| tristan | benschubert, but if we start, I can ponder this in the background and come back in a couple hours... | 09:06 |
| benschubert | tristan: sure :) Great. So for the cache-key tests, I wanted to allow plugin projects to be able to run them without writing the whole logic | 09:07 |
| tristan | benschubert, from a general perspective, I think that BuildStream should be offering API in buildstream.testing which plugin projects can use to register explicit tests in their own pytest test suite | 09:07 |
| tristan | I'm not particularly fond of the "Here buildstream: This is my plugin, now test it !" approach | 09:07 |
| tristan | But that's just a general feeling I have about buildstream.testing | 09:08 |
| benschubert | 2 ways I can see that: | 09:08 |
| benschubert | 1) We add a new method to the `Repo` that returns a project/elements and bst tests on this. Plus: it's very visible, minus: only for sources | 09:08 |
| benschubert | 2) Provid a set of "check" methods that plugins can use for testing, which can be much more general afterwards (when we see patterns, we add a helper and tada) | 09:08 |
| benschubert | ok I guess the 2. would therefore be the better solution | 09:08 |
| tristan | Right I think so | 09:09 |
| benschubert | So provide a `check_cache_keys_stability(path_to_project)` method that expects a project with the same layout as we have now in bst for cache keys as a start? | 09:09 |
| tristan | cache key tests are fairly simple, but they do require some responsibility and work on the authors part | 09:09 |
| tristan | Exporting the function that does the checks would be helpful | 09:10 |
| benschubert | cheers, I'll move that way then | 09:10 |
| benschubert | thanks! | 09:10 |
| tristan | benschubert, I would be happy with that, I think that since this is an external API we'll want to document that function well | 09:10 |
| benschubert | yep definitely | 09:11 |
| tristan | explaining how it works | 09:11 |
| tristan | Maybe we want to also provide the update program | 09:11 |
| tristan | which consequently also generates the .expected files when you first setup your test | 09:11 |
| benschubert | Do we have a `plugin author` documentation part? | 09:11 |
| tristan | Plugins I suppose we do not have full expectations of API stability or stability of cache keys (except for a subset of plugin projects which decide to offer that) | 09:11 |
| tristan | So the update program is also useful | 09:12 |
| tristan | benschubert, unfortunately not really, it's the last piece of docs we don't have a clean story for | 09:12 |
| tristan | we have some in the Element/Source/Plugin docs but that's it | 09:12 |
| * tristan has to run now... | 09:12 | |
| benschubert | yep good point. I'm not 100% sure how we'd end up exposing this. A new entrypoint that's added with `pip install buildstream[test]` ? | 09:12 |
| benschubert | tristan: ok. Fine with postponing the docs part of it? | 09:13 |
| benschubert | If someone has time, i'd appreciate reviews on! !1905, !1906, !1907, !1911 and https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/108 | 09:15 |
| *** Frazer has joined #buildstream | 10:04 | |
| Frazer | hi, is it ok to use an example in https://gitlab.com/BuildStream/buildstream/-/tree/master/doc/examples for this project https://github.com/github/linguist/tree/master/samples . this should hopefully add BuildStream as a known language to gitlab? | 10:10 |
| *** radiofree has joined #buildstream | 10:42 | |
| radiofree | Hello! | 10:44 |
| radiofree | i'm trying to get --format ${deps} to work, but it only ever seems to print "%{deps}" | 10:44 |
| radiofree | e.g using the example from the test (cd buildstream/tests/frontend/project) | 10:44 |
| radiofree | bst show --deps all checkout-deps.bst (shows dependencies) | 10:45 |
| benschubert | radiofree: what version of BuildStream are you on? | 10:45 |
| radiofree | bst show --deps all --format "%{name}: %{deps}" checkout-deps.bst | 10:45 |
| radiofree | this prints "import-dev.bst: %{deps}" | 10:45 |
| radiofree | 1.4.1 | 10:46 |
| benschubert | I don't think bst 1.4 supports '%{deps}' | 10:47 |
| benschubert | is it listed when you do `bst format --help` ? | 10:47 |
| radiofree | "Error: No such command 'format'." | 10:48 |
| coldtom | radiofree, bst show --help | 10:48 |
| coldtom | apparently it's not there | 10:48 |
| radiofree | ah, no | 10:49 |
| benschubert | ah right, show sorry | 10:49 |
| radiofree | that'll be why then :) | 10:50 |
| radiofree | must have been looking at the documentation for master | 10:51 |
| benschubert | tristan: https://gitlab.com/BuildStream/buildstream/-/merge_requests/1915/ how about this? It's lacking the script and the documentation, but that might be easier to add later? | 11:04 |
| jjardon | abderrahim[m]: have you seen https://gitlab.com/BuildStream/buildstream/-/merge_requests/1914 ? looks like a clean solution to the overlaps problems we have (or cleaner than the current one at least) | 11:29 |
| tristan | Frazer, The examples are meant to be usable samples, the intent is that anyone can use them | 12:14 |
| Frazer | tristan thanks, just making sure im not breaching anything | 12:19 |
| *** aminbegood has quit IRC | 12:21 | |
| *** aminbegood has joined #buildstream | 12:21 | |
| tristan | Frazer, yeah we don't have copyright/license headings in the bst files in BuildStream proper, it would probably make the documentation which those yaml files get literally rendered into very noisy and hard to read | 12:24 |
| tristan | Maybe we need to clarify that somehow | 12:24 |
| tristan | benschubert, I added a comment there, generally yeah looks good | 12:25 |
| benschubert | tristan: cheers, I'll address the comments, move the update script and such then | 12:25 |
| WSalmon | tristan, are they not covered by the main copyright notice and so tecnically lgpl? | 12:25 |
| tristan | benschubert, my comment is mostly: Lets make sure that everything public gets imported directly from `buildstream` or from `buildstream.testing` respectively, and not add new namespaces | 12:25 |
| tristan | WSalmon, I'm not sure | 12:25 |
| tristan | WSalmon, I think they are technically lgpl or fork-and-do-what-you-want-we-dont-care (even less binding than lgpl), but I can't say with exact certainty that we've expressed that correctly | 12:27 |
| benschubert | tristan: ah good point, I'll move that to `from buildstream.testing` | 12:27 |
| jjardon | tristan: would it be possible to release 1.4.3 soonish? I think the CI is fine now? | 12:44 |
| tristan | jjardon, CI is not fine | 12:47 |
| tristan | jjardon, https://gitlab.com/BuildStream/buildstream/-/merge_requests/1917 should make it fine | 12:47 |
| tristan | in theory | 12:47 |
| * tristan waits to see if this passes again | 12:48 | |
| tristan | jjardon, I can backport that to 1.4 branch if we want a new 1.4.x sure | 12:48 |
| tristan | jjardon, there is stuff you want in 1.4 soon then ? | 12:49 |
| jjardon | tristan: do we have a 1.4 branch? any new feature in bst-1 ? | 12:49 |
| jjardon | tristan: we need something is already in bst-1 | 12:49 |
| jjardon | we are using a patched bst-1 version at the moment | 12:49 |
| tristan | jjardon, not exactly yet, but I branched with the intention of landing https://gitlab.com/BuildStream/buildstream/-/merge_requests/1912 on it | 12:49 |
| tristan | and then CI blew up | 12:50 |
| tristan | jjardon, ok we'll roll another 1.4 then, no worries | 12:50 |
| jjardon | tristan: ah, ok. Nice thanks a lot! | 12:50 |
| tristan | I wanted to focus on getting bst-2 detection and other stuff into 1.6 but a micro point 1.4 is no trouble | 12:50 |
| jjardon | tristan: maybe more for 1.6, but maybe you can take a look to https://gitlab.com/BuildStream/buildstream/-/merge_requests/1914 as well; that will help junctions a lot | 12:51 |
| jjardon | in our case it will simplify GNOME's junction of fdsdk and it will make it less "hacky" | 12:51 |
| tristan | jjardon, I think there is an ongoing conversation about that | 12:52 |
| tristan | I frankly dislike the idea of anything injected into a junctioned project, we're working on providing more clarity around that and ensuring less of that happens, not more | 12:52 |
| tristan | this looks like a whole other MR, where is the original one | 12:53 |
| jjardon | tristan: in GNOME we need to replace glib, and other libraries; the current solution with filters is not ideal, and quite fragile | 12:53 |
| benschubert | the other MR is !1913. I would be against merging anything there until we had a ML discussion though | 12:54 |
| tristan | jjardon, to repeat my comment on the original (probably master targetting) MR: We need to work on making it easier for g-b-m to consume the dependencies with glib removed, not work on allowing g-b-m to modify how fdsdk cooks glib | 12:54 |
| jjardon | ah sorry, I didnt see the comments at https://gitlab.com/BuildStream/buildstream/-/merge_requests/1913 | 12:55 |
| * jjardon reads | 12:55 | |
| tristan | before we ever started buildstream, I was thinking of a dependency semantic "replaces", where once you get up to a certain part of the stack, you could have new elements replacing what gets staged at lower levels (this was from YBD/morph days) | 12:57 |
| tristan | I'm not sure it's exactly the right solution, and in BuildStream I would implement it differently | 12:58 |
| tristan | However, I do think it's interesting to note that this problem does not _only_ present itself because of junctions | 12:58 |
| tristan | jjardon, I think you were present years ago when we discussed how to get coreutils/bash to replace busybox once they are built and busybox is no longer needed | 12:59 |
| tristan | I think this is effectively the same thing (although a different use case) | 12:59 |
| jjardon | yep, I think I remember | 13:00 |
| tristan | Similar situations arise with cyclic build dependencies too, where for instance you have to build something without support for another thing, in order to build that other thing, so you can come back and build the first thing with support for the other | 13:02 |
| * tristan seems to recall something like that happening with libxml2 | 13:02 | |
| juergbi | valentind: can we close !1914 at least for now? I think it's only confusing/noisy if there is already a backport MR open for a feature that is still being discussed for master | 13:18 |
| juergbi | (I don't have objections to the branch for testing, of course, but there is no need for the MR right now) | 13:19 |
| *** cs-shadow has joined #buildstream | 13:19 | |
| tristan | Anyone wanna look at !1917 ? | 13:47 |
| valentind | juergbi, It is WIP. | 13:51 |
| *** seanborg_ has joined #buildstream | 13:51 | |
| *** seanborg has quit IRC | 13:52 | |
| juergbi | valentind: sure but what's the point in already opening an MR? discussing the backport is premature, imo. and it adds noise to the MR list | 13:52 |
| valentind | I will unmark WIP the master one first. Until it is resolved. But before I unmark I want the opinion of other people from g-b-m. | 13:52 |
| valentind | juergbi, It is to have a link to what has been effectively tested. | 13:53 |
| tristan | I think the point is that so far, there is a lot of doubt around that MR landing in buildstream at all, and we would like to see discussion on the list about the appropriate way to handle this class of problem | 13:59 |
| tristan | if it turns out that we really have to resort to overriding things in junctioned projects, I think that would be a last resort, but lets discuss other options first | 14:00 |
| tristan | benschubert, since you're working through plugin testing, do you know where the ostree `repo` implementation is located in the `bst-plugins-experimental` repo ? | 14:02 |
| tristan | Ah I found it | 14:03 |
| benschubert | tristan: not by heart, let me have a look (we need to reorganize all of this -_-) | 14:03 |
| tristan | benschubert, there is a `testing` module in src/bst_plugins_experimental | 14:05 |
| benschubert | that doesn't make sense :/ it should be in tests/ | 14:05 |
| tristan | which... is a little strange but might have to do with how buildstream itself uses bst_plugins_experimental in order to test it's own regressions against plugins | 14:06 |
| benschubert | no, we should not have to use those | 14:07 |
| tristan | we don't use the `repo` implementations from plugin packages ? | 14:09 |
| tristan | I'm really fuzzy on this tbh | 14:10 |
| juergbi | tristan: !1917 looks reasonable to me but I'm a bit surprised that the gpg stuff requires that many files | 14:10 |
| tristan | I don't know heh | 14:10 |
| juergbi | tristan: also, is pubring.kbx~ really needed or was this added accidentally? | 14:10 |
| tristan | juergbi, I just created a gpg key with the homedir set to that directory, and it generated all that | 14:10 |
| tristan | I found the ~ file strange as well | 14:10 |
| tristan | juergbi, it's possible that it works without all of the files, hard to know which ones are hard required | 14:11 |
| benschubert | tristan: actually could we just create them on the fly? | 14:11 |
| benschubert | tristan: we do, but from the tests of bst-plugins-experimental normally | 14:12 |
| benschubert | so it could just live there | 14:12 |
| tristan | benschubert, what are you talking about, the GPG keys ? | 14:14 |
| benschubert | yes sorry for the context switch | 14:14 |
| tristan | Hmmm, it's a bit awkward to do, ostree seems to store a key/homedir for this purpose too | 14:15 |
| tristan | it's a bit different than this one | 14:15 |
| benschubert | ok | 14:16 |
| tristan | Well, the answer is that we probably could; but it'd take a while ;-) | 14:16 |
| tristan | one thing which is annoying is I had to find out the name of the key with `gpg --list-keys` | 14:16 |
| tristan | probably there is a way to name a key and avoid all that | 14:17 |
| benschubert | ah sure, let's not bother then | 14:17 |
| tristan | I've also got: https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/109 | 14:18 |
| tristan | That test passes locally, we'll see what it does in CI | 14:18 |
| benschubert | Who's in charge of buildstream-bastion-overnight ? I can't get a nightly build to finish: https://gitlab.com/BuildStream/buildstream/-/jobs/546419118 | 14:47 |
| *** aminbegood has quit IRC | 14:56 | |
| *** phoenix has joined #buildstream | 15:09 | |
| *** seanborg_ has quit IRC | 15:24 | |
| *** seanborg_ has joined #buildstream | 15:24 | |
| benschubert | juergbi: ^ do you know by any chance? :) | 15:45 |
| juergbi | benschubert: benbrown, jjardon, valentind ^^ | 15:46 |
| benschubert | oh thanks | 15:48 |
| benschubert | tristan: looking at the script to automatically update cache keys. It's tricky: | 15:51 |
| benschubert | - We don't want that in entry_points for BuildStream, as it would pollute installs | 15:51 |
| benschubert | - We can't really have a switch in the check method itself as we might be working in a tmpdir so our change would not persist. | 15:51 |
| benschubert | - Having an ad-hoc script would still mean users need to copy it and won't have nice interface. | 15:51 |
| benschubert | So... should we provide the function to update and users are left to add it in a python script? Any other idea? | 15:51 |
| cs-shadow | can't we do something like `python -m `buildstream.testing.update_keys` ? | 15:54 |
| cs-shadow | and with correct quoting - `python -m buildstream.testing.update_keys` | 15:55 |
| benschubert | oh that's a good point. I'll go for this | 15:55 |
| cs-shadow | this method,could in turn call the underlying method for checking/rewriting the cache keys. The difference compared to tests would be that this will pass the real path to the tests, not a tmpdir | 15:56 |
| WSalmon | juergbi, i have no idea what https://gitlab.com/BuildStream/buildstream/-/merge_requests/1718/diffs dose it is not code i am familiar with, do you think this patch is way buildstream always seems to pull from the bottom up? | 16:02 |
| juergbi | WSalmon: possibly. if you have time to create a test case for this pull issue, I can try to revert the relevant commit | 16:04 |
| valentind | benschubert, Sorry, did not see. Do you still have a problem with the CI? | 16:10 |
| benschubert | valentind: yeah, didn't get a single one ending in 4 tries, that's the nightly build so it takes a very long time | 16:10 |
| valentind | It looks like the timeout was reached. | 16:11 |
| valentind | Timeout: 20h (from project) | 16:11 |
| benschubert | valentind: no that's the total timeout. Time was 305min before it was killed | 16:11 |
| benschubert | (Duration: 305 minutes 53 seconds ) | 16:12 |
| benschubert | so the runner times out roughly after 5 hours? | 16:12 |
| WSalmon | juergbi, sounds like a plan | 16:12 |
| valentind | Right. I think it is 6. | 16:13 |
| valentind | benschubert, I can change that. | 16:13 |
| valentind | The problem is that the gitlab runner leaves so many dead builders that we have to forcefully clean them up. | 16:13 |
| benschubert | valentind: thanks! Otherwise we can reduce what we build for the nightly fsdk test, which is also fine by me | 16:13 |
| valentind | I thought it was 12 hours. But maybe it was 6. I have to check. | 16:13 |
| benschubert | sure, keep me updated, thanks | 16:14 |
| valentind | benschubert, I put the timeout to 12 hours. | 16:17 |
| benschubert | thanks! I'll see if I manage to finish a build now :) | 16:18 |
| valentind | That might still happen. It would just be nice if gitlab fixed the runner and cleanup correctly builders. | 16:18 |
| juergbi | valentind: I assume that issue is related to the docker-machine digitalocean issue (API limits) | 16:19 |
| valentind | juergbi, There are 2 bugs I think. | 16:20 |
| juergbi | kubernetes is probably the best long term bet. possible alternatives are to reduce the number of DO API calls in the docker-machine backend or moving away from DO | 16:20 |
| valentind | But yes it is around docker-machine. | 16:20 |
| valentind | Sure. Though I will not touch kubernetes. I do not have time for that. | 16:21 |
| juergbi | sure, I understand. same here | 16:21 |
| *** jude has quit IRC | 16:28 | |
| *** santi has quit IRC | 16:37 | |
| *** santi has joined #buildstream | 16:42 | |
| *** pointswaves has joined #buildstream | 17:30 | |
| *** seanborg_ has quit IRC | 17:34 | |
| *** santi has quit IRC | 17:59 | |
| *** chipb_ is now known as chipb | 18:31 | |
| *** tpollard has quit IRC | 18:41 | |
| *** aminbegood has joined #buildstream | 19:37 | |
| *** aminbegood has quit IRC | 20:07 | |
| *** toscalix has joined #buildstream | 20:22 | |
| *** cs-shadow has quit IRC | 21:09 | |
| *** toscalix has quit IRC | 21:29 | |
| *** phoenix has quit IRC | 22:11 | |
| *** pointswaves has quit IRC | 22:20 | |
| *** benschubert has quit IRC | 23:00 | |
| *** rdale has quit IRC | 23:32 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!