*** tristan has quit IRC | 00:08 | |
gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 00:19 |
---|---|---|
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 | 01:38 |
*** tristan has joined #buildstream | 02:23 | |
*** Prince781 has joined #buildstream | 02:32 | |
*** Prince781 has quit IRC | 02:34 | |
*** Prince781 has joined #buildstream | 02:36 | |
*** Prince781 has quit IRC | 02:40 | |
*** tristan has quit IRC | 03:58 | |
*** toscalix has joined #buildstream | 06:06 | |
gitlab-br-bot | buildstream: issue #301 ("Fix circular imports") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/301 | 06:24 |
*** ernestask has joined #buildstream | 06:52 | |
toscalix | laurence: anything urgent I need to take a look at? I have 30 min. | 07:06 |
toscalix | I just went through the tickets notifications and pending mails | 07:06 |
toscalix | I still have a few more discussions in tickets to process. | 07:06 |
jmac | I don't think any of the other Codethink people are in, toscalix | 07:08 |
toscalix | laurence: usually is an early bird. I will try to connect again before going to bed | 07:09 |
toscalix | we have improve in the usage of tickets | 07:09 |
toscalix | but not enough to keep good track of what is going on just by looking to the notifications and the boards | 07:10 |
toscalix | still there is some work to do in this regard | 07:10 |
toscalix | I am "suffering" these couple of weeks I am traveling and at events | 07:10 |
toscalix | we will get there, I am sure | 07:11 |
*** finn has quit IRC | 07:53 | |
*** coldtom has joined #buildstream | 07:54 | |
*** toscalix has quit IRC | 07:57 | |
*** bethw has joined #buildstream | 08:04 | |
*** Phil has joined #buildstream | 08:13 | |
laurence | toscalix, i am trying to tidy up tickets this week and improve usage, enforcing good habits | 08:20 |
*** mohan43u has joined #buildstream | 08:21 | |
*** jonathanmaw has joined #buildstream | 08:58 | |
gitlab-br-bot | buildstream: issue #434 ("Add documentation on workspaces") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/434 | 09:12 |
*** dominic has joined #buildstream | 09:25 | |
gitlab-br-bot | buildstream: merge request (gokcen/source_transform->master: WIP: Source transform plugin) #505 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/505 | 09:28 |
*** aday has joined #buildstream | 09:53 | |
*** noisecell has quit IRC | 10:00 | |
*** noisecell has joined #buildstream | 10:16 | |
*** noisecell has quit IRC | 10:22 | |
*** noisecell has joined #buildstream | 10:30 | |
*** aday has quit IRC | 10:35 | |
*** aday has joined #buildstream | 10:36 | |
*** noisecell has quit IRC | 11:45 | |
gitlab-br-bot | buildstream: merge request (chandan/bst-from-workspace->master: WIP: Allow running bst commands from worksapce directory) #510 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/510 | 11:57 |
*** noisecell has joined #buildstream | 12:02 | |
*** ernestask has quit IRC | 12:09 | |
tlater | noisecell: For deployment, you'll probably want to create a custom deployable plugin for whatever infrastructure you're deploying to. | 13:18 |
tlater | You can then retrieve the relevant files with `bst checkout` | 13:18 |
tlater | If there's anything more specific you need help with it might be a bit easier to explain a workflow :) | 13:18 |
noisecell | tlater, in configure-extensions and write-extensions in ybd and morph use to modify /etc and other internal bits which Im not sure if buildstream allows it | 13:19 |
tlater | noisecell: Could a "compose" element be what you want? | 13:19 |
noisecell | tlater, no, I need a stack and then an x86Image kind | 13:21 |
tlater | And you would like to modify files in /etc/ of the resulting image? | 13:21 |
noisecell | but I need to add the same functionality as we did in the past: https://gitlab.com/baserock/definitions/blob/b4ebdf21351dd156c117832f56753c97a1450e74/unmaintained/systems/openstack-system-x86_64.morph | 13:22 |
noisecell | where we were modifying, adding and installing files in /etc | 13:22 |
noisecell | these extensions were python and shell scripts which run in deploy time inside the image and allows you to change the Image previously the deployment phase happens, AFAICR | 13:24 |
tlater | noisecell: So these would change depending on the host you deployed your image to? | 13:25 |
tlater | If the information was static, you could achieve this by simply putting a few manual/compose elements on top of your stack | 13:25 |
noisecell | that was depending on the information you wrote in the cluster: https://gitlab.com/baserock/definitions/blob/b4ebdf21351dd156c117832f56753c97a1450e74/unmaintained/clusters/openstack-three-node-installer.morph | 13:26 |
noisecell | https://gitlab.com/baserock/definitions/blob/b4ebdf21351dd156c117832f56753c97a1450e74/unmaintained/clusters/openstack-one-node.morph | 13:26 |
tlater | Right | 13:26 |
tlater | I think you can achieve something similar with variables in buildstream, let me just check... | 13:26 |
tlater | noisecell: This could do what you want: https://buildstream.gitlab.io/buildstream/format_project.html#options | 13:27 |
tlater | Although it may be a bit more cumbersome, you'd have to specify your options and re-build the relevant set of elements every time you want to deploy to a new system. | 13:28 |
tlater | (Sam had a conversion script from morph -> buildstream, I take it you're aware of that, noisecell?) | 13:32 |
noisecell | tlater, yeah, but all the configuration extensions and write extensions were ignored, as far as I can tell :) | 13:32 |
tlater | Yeah, I figured, we grew options a while after he wrote that script | 13:33 |
tlater | It seems *technically* possible, just perhaps too cumbersome to actually use. Allowing --options to read a file or something would be nice | 13:33 |
noisecell | tlater, these extensions are more a deployment extensions than a build extensions as far as I remember | 13:33 |
tlater | Yup, I understand. The way I imagine this to work is to have a set of elements which perform the changes necessary for deployment, and change what they do based on buildstream options. | 13:34 |
tlater | That way you can set things like secret keys for individual system images. | 13:34 |
noisecell | tlater, probably I will need a compose element with what I need, then an x86Image or any other plugin depending on the target and in that plugin add these extensions | 13:34 |
tlater | noisecell: I would add an element on top of the target, which then adds the extensions | 13:35 |
tlater | That way when you call `bst build`, you will rebuild the extensions whenever you change how your target is supposed to behave, and only take minimal time. | 13:36 |
tlater | I suspect that this is sort of how these morph/ybd extensions worked, except the functionality was a bit more explicit. | 13:36 |
noisecell | tlater, thank you for the info, Im going to see if I can find the way :) | 13:37 |
tlater | noisecell: If you do find a nice workflow, don't feel shy to document it :) | 13:37 |
noisecell | tlater, sure :) | 13:38 |
*** finn_ has joined #buildstream | 13:51 | |
finn_ | Hi, about to set up unittests for BuildGrid | 13:51 |
finn_ | Anyone got any strong opinions? | 13:52 |
finn_ | I was considering keeping it simple and just using the standard unittest library | 13:52 |
finn_ | tlater usually has a good opinion | 13:52 |
*** dominic has quit IRC | 13:52 | |
*** dominic has joined #buildstream | 13:52 | |
tlater | finn_: We use pytest in buildstream | 13:52 |
finn_ | any reason? | 13:53 |
tlater | It has a few nice features over the standard library, mostly neat decorators | 13:53 |
tlater | There's one specific one but I can't think of the name... | 13:53 |
tlater | It allows you to specify multiple datasets and run the same test on them | 13:53 |
tlater | Overall, having played with both, it just makes tests less verbose | 13:54 |
tlater | finn_: If you use pytest, you can also use this to get it to run nicely with `./setup.py test`: https://pypi.org/project/pytest-runner/ | 13:55 |
tlater | You can also think about adding a linter, I recommend https://www.pylint.org/, but there's also pyflake & co. pylint seems to be the most complete by default, but it lacks some pep8 coverage. | 13:56 |
tlater | Ah, finn_, this is why I like pytest over stdlib: https://docs.pytest.org/en/latest/parametrize.html#pytest-mark-parametrize | 13:57 |
finn_ | So it's shorter and neater | 14:01 |
tlater | Yep. The trade-off is another dependency, but I tend to find that that matters lest for test suites. | 14:02 |
noisecell | tlater, are you distinguishing between test and core dependencies? | 14:06 |
tlater | Yes | 14:06 |
* tlater finds that sensible, since users rarely run tests | 14:07 | |
noisecell | cool :) | 14:07 |
*** aday has quit IRC | 14:20 | |
*** aday has joined #buildstream | 14:23 | |
noisecell | are there any magic commands to clean my cache but the elements Im using from one build? | 14:24 |
tlater | noisecell: No. That's my fault too, buildstream will soon do this automatically. | 14:24 |
tlater | Hopefully next week | 14:24 |
gitlab-br-bot | buildstream: issue #435 ("small bu impactful typo in doc/source/index.rst") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/435 | 14:25 |
noisecell | tlater, ok, thanks :) | 14:26 |
gitlab-br-bot | buildstream: merge request (patch-1->master: fix tiny, but impactful typo) #511 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/511 | 14:26 |
*** Prince781 has joined #buildstream | 14:36 | |
gitlab-br-bot | buildstream: merge request (phil/203-BuildStream-crashes-when-dependency-tree-too-deep->master: WIP: Phil/203 build stream crashes when dependency tree too deep) #512 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/512 | 15:00 |
*** aday has quit IRC | 15:01 | |
*** aday has joined #buildstream | 15:03 | |
*** tristan has joined #buildstream | 15:04 | |
tristan | Nexus, are you around ? | 15:14 |
tristan | Nexus, I was going to take a shower and head out to a work location but remembered we should chat before it's too late over there | 15:15 |
Nexus | o/ | 15:21 |
tristan | ah ! :) | 15:21 |
Nexus | this about the reducing history MR? | 15:22 |
tristan | https://gitlab.com/BuildStream/buildstream/merge_requests/482 | 15:22 |
tristan | Nexus, just went and pulled it up yeah | 15:22 |
tristan | Nexus, we had a meeting the other day and I promised to touch base while the stars align :) | 15:23 |
Nexus | Ok, so i've talked with skullman about this issue, and it seems like what was discussed on #git, won't work for what we need to do | 15:23 |
tristan | Nexus, have you understood the race condition and the issues with the current approach, and have you digested https://gitlab.com/BuildStream/buildstream/merge_requests/482#note_82696943 | 15:24 |
skullman | I'm currently writing up our understanding. | 15:24 |
tristan | ? | 15:24 |
Nexus | tristan: regarding the use of HEAD/ | 15:24 |
Nexus | ? | 15:24 |
Nexus | yes | 15:24 |
tristan | Ok | 15:24 |
Nexus | i'm looking into an alternative atm | 15:24 |
skullman | I don't think --shared or --reference would be useful though. | 15:25 |
tristan | I'm not altogether clear on whether all the details align (can we fetch a specific sha ?), but the theory seems clean and nice | 15:25 |
tristan | skullman, no ? | 15:25 |
skullman | --reference is for if we're cloning from upstream and happen to know we have a repository locally that shares some of the history, while instead we fetch into a local mirror at the fetch stage and do future operations with that | 15:26 |
skullman | --shared would require us to bind-mount the repository from the source cache into the staging area | 15:26 |
Nexus | tristan: there is a way to do what i did directly with the SHA instead of HEAD, it's just a bit fiddly, so i'm getting my head around the specifics atm | 15:26 |
tristan | skullman, it can be --dissociate -ed though | 15:27 |
tristan | skullman, so you can build the "exactly what you need" using fetch, and then dissociate the child repo | 15:27 |
skullman | tristan: --dissociate is only for use with --reference. --dissociate and --shared don't work together since it's equivalent to --local | 15:27 |
tristan | Oh, well then why not with --reference ? I think that's what rafsac is suggesting too | 15:28 |
skullman | That would be like `git clone --reference /path/to/local/mirror.git git://url/to/upstream.git` | 15:29 |
tristan | So there are two things, one thing is the racy peeking at head, the other thing is our current approach makes some assumptions, or lets say: carries a lot of burden of knowledge of git internals | 15:29 |
skullman | we've already fetched all the content from git://url/to/upstream.git into /path/to/local/mirror.git by the time we make this repository | 15:29 |
tristan | I can't say for sure I understand exactly what rafsac is saying about "divergence", but it could be that the logic of presuming depth will add up to all the objects we need is not true in all cases | 15:30 |
skullman | which is why we're looking at --shallow-exclude | 15:31 |
tristan | skullman, yes, I mean we create /path/to/temp/staging/dir as a git clone --reference of it's upstream, which is /path/to/local/mirror.git | 15:31 |
skullman | that's a git clone --shared not a git clone --reference then | 15:31 |
tristan | skullman, in the repo we're about to stage, we just create it as a reference, fetch the commit/ref we want, ensure we have tags for the history up until then, and dissociate | 15:31 |
tristan | Whether it's --shared or --reference, I'm not sure of the detail; my understanding is that git can do this | 15:32 |
tristan | make this referencing/sharing(whichever) thing which will use git's own knowledge to construct a child repo with only the history we needed to stage that commit | 15:33 |
tristan | not sure which is the right one, but it needs to be dissociated after | 15:33 |
tristan | i.e. git describe will run when the parent repo is not in sight | 15:34 |
skullman | the only way to get a shallow history is via the fetch or clone commands and fetch lets you do so without adding unwanted branches that you'd only have to delete later. the benefit of dissociate is not needing to know the internal commands necessary to clean it back up afterwards, and as I understand our current shallow fetch approach the reflog deletion and repacking steps won't be necessary | 15:38 |
gitlab-br-bot | buildstream: merge request (phil/203-BuildStream-crashes-when-dependency-tree-too-deep->master: WIP: Phil/203 build stream crashes when dependency tree too deep) #512 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/512 | 15:47 |
finn_ | Anyone with logging experience, mind taking a look at this? | 15:47 |
finn_ | https://gitlab.com/BuildGrid/buildgrid/merge_requests/4 | 15:47 |
Nexus | tristan: this should be entirely possible without messing around with --shared or --reference, even if they did what we wanted | 15:49 |
tlater | finn_: Without looking too closely, you may want to look at a standardized logging format, ala apache, nginx. It makes it a lot easier to plug in information parsers when you're actually hosting one of these things. | 15:49 |
tristan | skullman, I've been re-reading this a few times - and your sentence above, I'm not sure I'm making sense of --dissociate | 15:50 |
tristan | skullman, but I don't know what you're cooking up with shallow exclude either, my understanding was that was also fiddly as it might involve more history arithmetic | 15:51 |
finn_ | Thanks tlater, I may raise it as an issue | 15:52 |
skullman | tristan: --shallow-exclude is new since when I'd looked at how to do exactly what we're after 2 years ago, we think we can use it to do it without history arithmetic, but history arithmetic can be done without being racy. | 15:53 |
coldtom | how do i test push features? i can't get a repo to support push | 15:53 |
tristan | Also I thought you potentially need to specify shallow exclude more than once | 15:53 |
skullman | yeah, for all parent commits of the tag | 15:53 |
skullman | I don't see this as a problem. | 15:53 |
tristan | However - If this can be done without history arithmetic, and with minimal understanding of internal git voodoo, that is superior | 15:54 |
tristan | So you mean... you would have to write a loop which checks all the parents of the tag, and concoct a command line which specifies --shallow-exclude for each of them on the clone ? | 15:55 |
skullman | tristan: doesn't have to be a loop, but yes, we can get git to tell us all of the parents and construct a command line that includes a --shallow-exclude for each | 15:55 |
tristan | I mean... *if* there is a way that we can use a "view" repo temporarily, just fetch what we need, and pack in the objects as a result; then it's certainly nicer to make git do what it knows how to do | 15:55 |
Nexus | but getting the parents of a commit is something that git knows how to do | 15:56 |
tristan | maybe there is a flaw in that plan, maybe it is not possible | 15:56 |
skullman | doesn't buy us anything, since we can do all read operations on the mirror, and there's only one write operation we need to do | 15:56 |
tristan | I dont understand... if it buys us "not having to know about parents of commits and how to exclude them", it seems to buy us a lot | 15:58 |
skullman | We can't construct a shallow history at all without knowing that. --shallow-exclude or history arithmetic and --depth are the only options. I've looked at this extensively at this point and understand it to be the minimum voodoo. | 15:59 |
skullman | The alternative is to give up on shallow history. | 15:59 |
Nexus | tristan: is your concern that you don't want git logic in the code? | 15:59 |
tristan | Nexus, definitely I want it to be minimal | 16:00 |
tristan | it's a concern that we put complex knowledge there because someone happens to know how at the time; this should be absolutely necessary | 16:00 |
Nexus | tristan: if you want to remove histroy, some complex knowledge is required to some degree | 16:02 |
gitlab-br-bot | buildstream: issue #246 ("Documentation sidebar changes from page to page") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/246 | 16:02 |
Nexus | it's not a normal thing to do, and one of the first things said in your talk yesterday was "that's a hard problem." | 16:02 |
Nexus | there isn't a one line fix | 16:02 |
tristan | Nexus, if it must be there it must, I'd really like to understand why the really attractive option without that doesnt work, though | 16:05 |
tristan | So I'm hearing from there that the only way to do it at all, is to either count depth (#git dude recommended against this approach), or manually specify --exclude flags the chop off history; and that the view/pack approach is just orthogonal and doesnt buy us anything | 16:07 |
tristan | s/from there/from here | 16:07 |
skullman | That is my understanding. | 16:10 |
tlater | Is there a `bst build --no-push` or somesuch? I'd like to run a CLI build that explicitly doesn't push | 16:13 |
tlater | *CI | 16:13 |
skullman | I can't find any documentation that would suggest --dissociate valid during any operation except clone anyway, so we can't create a shared repository, do some changes and then dissociate later. | 16:13 |
tristan | I'm thinking this should be in like 4 steps | 16:13 |
Nexus | --shared would require the alternate repo (mirror) to be available at all times including after being cached in order to function properly. The --reference would require both that and an upstream repo, and after being dissacociated will stil lneed the upstream repo to be available, meaning it could never be used offline. And you cannot use --dissociate with --shared There is no way to, after | 16:13 |
jmac | tlater: I don't think so | 16:13 |
tristan | o git clone --reference-or-shared mirror.git | 16:13 |
Nexus | making the repo dependent on an alternate repo, remove that dependency. If you do so, the repo will break. | 16:13 |
tristan | o git fetch the <commit sha> we need | 16:13 |
tristan | o git make sure we have the tags | 16:13 |
tlater | jmac: So I have to first remove the remote from my config and then add it back? Annoying :| | 16:14 |
tristan | o git pack --make sure we have the data and dont need the parent anymore | 16:14 |
tristan | I think I'll take a shower and try to spend some time fiddling with shell scripts :-S | 16:15 |
tlater | tristan has efficient showers. Waterproof laptop? | 16:15 |
tlater | ;p | 16:15 |
Nexus | alternative: Step 1: Fetch a shallow version of the repo which stops at the tag | 16:15 |
Nexus | step 2: remove all reference to unreachable commits | 16:15 |
Nexus | step 3: repack | 16:16 |
skullman | Nexus: don't even need to do step 2 or 3 | 16:16 |
Nexus | skullman: if we do shallow-exclude and remove parents yes | 16:16 |
jmac | tlater: Try "--pushers 0"? I'm not clear on how the scheduler uses that value, but it might work | 16:16 |
Nexus | then we'd have everything on step 1 | 16:16 |
tlater | Ah, right, there were those values | 16:16 |
tlater | ta jmac | 16:16 |
skullman | Nexus: that's essential however we do it. Steps 2 and 3 are left over from before fetching the commit we're after directly, when we thought we had to find a branch it was on, fetch that, then later prune the history after it. | 16:17 |
Nexus | skullman: So we now just need to shallow-exclude all parents of the tag, while fetching the ref, and we have everything in the state we need it? | 16:18 |
skullman | yep, the two steps are 1. a complicated fetch and 2. checkout FETCH_HEAD | 16:19 |
Nexus | that seems to me like the best option | 16:19 |
Nexus | since it avoids pulling n things you don't need, and them having to remove them | 16:19 |
jmac | tlater: Actually I think that might just leave jobs waiting forever for a push :/ | 16:21 |
tlater | I suspect so too, but it's worth a try :) | 16:21 |
gitlab-br-bot | buildstream: merge request (jjardon/getting_started->master: Add getting started section) #323 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/323 | 16:21 |
tlater | (if it does we may want to think about *not* making it do so) | 16:21 |
tlater | I also wonder what it does with -1 | 16:21 |
tlater | As many as possible? | 16:22 |
jmac | tlater: Yeah, I think '--pushers 0' would be a good way to specify no pushes | 16:22 |
gitlab-br-bot | buildstream: merge request (patch-1->master: fix tiny, but impactful typo) #511 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/511 | 16:25 |
*** aday has quit IRC | 16:25 | |
*** aday has joined #buildstream | 16:28 | |
gitlab-br-bot | buildstream: merge request (patch-1->master: fix tiny, but impactful typo) #511 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/511 | 16:32 |
gitlab-br-bot | buildstream: merge request (430-buildstream-doap-is-incorrectly-included-in-manifest-in->master: Resolve "BuildStream.doap is incorrectly included in MANIFEST.in") #508 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/508 | 16:33 |
gitlab-br-bot | buildstream: merge request (patch-1->master: fix tiny, but impactful typo) #511 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/511 | 16:34 |
*** mohan43u has quit IRC | 16:36 | |
gitlab-br-bot | buildstream: issue #436 ("Include install instructions for Ubuntu in the 'Install' section of the documentation") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/436 | 16:37 |
tlater | jmac: Interestingly, --pushers 0 does seem to work as intended | 16:43 |
tlater | Or, well, as we interpreted it | 16:44 |
*** Phil has quit IRC | 16:49 | |
gitlab-br-bot | buildstream: issue #437 ("Improve documentation for advanced features of BuildStream") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/437 | 16:50 |
laurence | I've opened up this issue re improving documentation for advanced features of buildstream - https://gitlab.com/BuildStream/buildstream/issues/437 | 16:51 |
laurence | any and all feedback welcome | 16:51 |
*** mohan43u has joined #buildstream | 16:52 | |
gitlab-br-bot | buildstream: merge request (138-aborting-bst-push-command-causes-stack-trace-2->master: WIP: Resolve "aborting bst push command causes stack trace") #513 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/513 | 16:53 |
*** mohan43u has quit IRC | 16:55 | |
*** bethw has quit IRC | 16:57 | |
*** dominic has quit IRC | 16:58 | |
gitlab-br-bot | buildstream: merge request (138-aborting-bst-push-command-causes-stack-trace-2->master: WIP: Resolve "aborting bst push command causes stack trace") #513 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/513 | 17:11 |
gitlab-br-bot | buildstream: merge request (138-aborting-bst-push-command-causes-stack-trace-2->master: WIP: Resolve "aborting bst push command causes stack trace") #513 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/513 | 17:12 |
gitlab-br-bot | buildstream: merge request (138-aborting-bst-push-command-causes-stack-trace-2->master: WIP: Resolve "aborting bst push command causes stack trace") #513 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/513 | 17:13 |
gitlab-br-bot | buildstream: merge request (138-aborting-bst-push-command-causes-stack-trace-2->master: WIP: Resolve "aborting bst push command causes stack trace") #513 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/513 | 17:13 |
gitlab-br-bot | buildstream: merge request (138-aborting-bst-push-command-causes-stack-trace-2->master: WIP: Resolve "aborting bst push command causes stack trace") #513 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/513 | 17:13 |
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 | 17:15 |
gitlab-br-bot | buildstream: merge request (138-aborting-bst-push-command-causes-stack-trace-3->master: WIP: Resolve "aborting bst push command causes stack trace") #514 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/514 | 17:16 |
*** coldtom has quit IRC | 17:16 | |
*** jonathanmaw has quit IRC | 17:19 | |
*** tristan has quit IRC | 17:29 | |
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 | 17:29 |
gitlab-br-bot | buildstream: merge request (jjardon/host_deps->master: Document Buildstream's plugins host packages dependencies) #495 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/495 | 18:44 |
gitlab-br-bot | buildstream: merge request (jjardon/host_deps->master: Document Buildstream's plugins host packages dependencies) #495 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/495 | 18:46 |
*** tristan has joined #buildstream | 18:48 | |
gitlab-br-bot | buildstream: issue #207 ("Can we replace/simplify some os.path.join()s for performance?") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/207 | 19:05 |
*** kelli365 has quit IRC | 19:32 | |
gitlab-br-bot | buildstream: merge request (patch-1->master: fix tiny, but impactful typo) #511 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/511 | 20:04 |
gitlab-br-bot | buildstream: issue #435 ("small but impactful typo in doc/source/index.rst") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/435 | 20:05 |
*** tristan has quit IRC | 20:15 | |
*** tristan has joined #buildstream | 20:48 | |
*** Prince781 has quit IRC | 21:02 | |
*** j1mc_polari has quit IRC | 21:30 | |
*** jcampbell has joined #buildstream | 21:31 | |
gitlab-br-bot | buildstream: merge request (430-buildstream-doap-is-incorrectly-included-in-manifest-in->master: Resolve "BuildStream.doap is incorrectly included in MANIFEST.in") #508 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/508 | 23:32 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!