| *** tristan has joined #buildstream | 05:06 | |
| *** toscalix has joined #buildstream | 07:53 | |
| *** bethw has joined #buildstream | 07:55 | |
| gitlab-br-bot | buildstream: merge request (jjardon/codequality->master: Add job to analyze project code quality with Code Climate CLI) #431 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/431 | 08:31 |
|---|---|---|
| *** jonathanmaw has joined #buildstream | 08:36 | |
| skullman | juergbi: I looked at the tar cache, but didn't have anything to start with to look at CAS. I'll do some research on CAS to see if this is going to be a problem. | 09:06 |
| gitlab-br-bot | buildstream: merge request (372-allow-queues-to-run-auxilliary-jobs-after-an-element-s-job-finishes->master: Resolve "Allow queues to run auxilliary jobs after an element's job finishes") #433 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/433 | 09:13 |
| gitlab-br-bot | buildstream: merge request (372-allow-queues-to-run-auxilliary-jobs-after-an-element-s-job-finishes->master: WIP: Resolve "Allow queues to run auxilliary jobs after an element's job finishes") #433 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/433 | 09:13 |
| *** dominic has joined #buildstream | 09:17 | |
| gitlab-br-bot | buildstream: merge request (getting-started-section->master: WIP: Getting started section) #418 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/418 | 09:32 |
| *** jjardon has quit IRC | 09:34 | |
| *** jjardon has joined #buildstream | 09:34 | |
| gitlab-br-bot | buildstream: merge request (372-allow-queues-to-run-auxilliary-jobs-after-an-element-s-job-finishes->master: WIP: Resolve "Allow queues to run auxilliary jobs after an element's job finishes") #433 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/433 | 09:39 |
| gitlab-br-bot | buildstream: merge request (372-allow-queues-to-run-auxilliary-jobs-after-an-element-s-job-finishes->master: WIP: Resolve "Allow queues to run auxilliary jobs after an element's job finishes") #433 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/433 | 09:53 |
| gitlab-br-bot | buildstream: merge request (jjardon/codequality->master: Add job to analyze project code quality with Code Climate CLI) #431 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/431 | 09:54 |
| 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 | 09:54 |
| 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 | 09:56 |
| *** aday has joined #buildstream | 10:09 | |
| gitlab-br-bot | buildstream: merge request (372-allow-queues-to-run-auxilliary-jobs-after-an-element-s-job-finishes->master: WIP: Resolve "Allow queues to run auxilliary jobs after an element's job finishes") #433 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/433 | 10:39 |
| gitlab-br-bot | buildstream: merge request (jennis/136-clean-remote-cache->master: WIP: jennis/136 clean remote cache) #421 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/421 | 10:55 |
| Nexus | tristan & juergbi: regarding #376, what would we do in the situation where the latest tag is newer than the `ref` commit? | 10:59 |
| tristan | Nexus, we need a checkout of the exact ref; to yield the intended `git describe` result for "that ref" | 11:01 |
| gitlab-br-bot | buildstream: merge request (jjardon/debian-9->master: .gitlab-ci.yml: Run test in current Debian stable (stretch)) #425 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/425 | 11:01 |
| tristan | Nexus, where a ref is a given commit sha | 11:01 |
| tristan | Nexus, so in this context, what we mean is the latest tag in the history leading up to that commit sha (not the latest tag in the repository) | 11:02 |
| Nexus | ah i see | 11:02 |
| juergbi | Nexus: in case you're not familiar with it, you can use `git describe --tags --abbrev=0 SHA` to get that tag | 11:15 |
| juergbi | --tags is to also support unannotated tags. we probably need to first try without --tags and only if that yields no match, try with --tags | 11:16 |
| jjardon | anyone around to review https://gitlab.com/BuildStream/buildstream/merge_requests/425 ? The MR says "No changes to code quality" :) | 12:07 |
| tlater | juergbi: You mentioned that the scheduler will need reworking for CAS - as far as I can tell this is so that we can schedule changes to the pipeline after pulling. | 12:09 |
| tlater | I'm in the middle of refactoring the scheduler anyway, maybe we should sync up on what you'd need to change for that? | 12:09 |
| juergbi | tlater: I wouldn't call it reworking, just adding a feature, hopefully without a big conflict | 12:11 |
| juergbi | tlater: What I need for CAS is just to be able to queue an Element later on if it was not in the originally queued plan | 12:11 |
| juergbi | i.e., completely remove build-only dependencies from the initial plan and add them only when the need arises | 12:12 |
| tlater | Ah, ok | 12:13 |
| juergbi | these elements would always be added to the first non-track queue | 12:13 |
| * tlater is considering adding a Scheduler.schedule_job function | 12:13 | |
| tlater | Because other schedule-after-initial-pipeline jobs will need to be launched somehow | 12:13 |
| juergbi | there is one tricky aspect with regards to build-only dependencies that are part of the elements that are tracked | 12:14 |
| juergbi | ideally, we remove them from the pipeline after the track queue and re-insert them into the pull/fetch queue when/if needed | 12:14 |
| juergbi | however, master doesn't have this optimization right now, so it wouldn't be a regression if we postponed this for later | 12:15 |
| tlater | I think that could be quite easy to implement | 12:15 |
| juergbi | sounds good | 12:16 |
| tristan | tlater, try to keep a clear roles and responsibilities of where things are being scheduled | 12:16 |
| tristan | tlater, as it stands now, the queue holds the jobs, and the scheduler pops them off in sched() | 12:16 |
| tristan | if you add schedule_job(), then there is now two places where the jobs live | 12:17 |
| juergbi | Yes, that's a bit of an issue for the CAS part. Not sure yet how to handle that best. | 12:17 |
| juergbi | Right now the Pipeline class handles initial queueing | 12:17 |
| juergbi | However, the Pipeline class is not necessarily involved in dynamic queueing | 12:17 |
| tristan | Right, it sets up the Queues, I want to change what's doing that but it doesnt change that the scheduler is "given queues" | 12:18 |
| tlater | tristan: In my mind the scheduler is given jobs, and delegates them to the correct queues | 12:18 |
| tristan | To clarify, what I want is: A.) A class which is responsible for initializing/loading elements, and providing functions for creating lists from the loaded build graphs | 12:18 |
| tristan | This will probably remain "Pipeline" | 12:18 |
| tristan | Then I want B.) A sort of main which you can give these lists to, which does the build, fetch, track, etc... and *it* takes the lists which pipeline has let you set up | 12:19 |
| tristan | tlater, right, some cleanup is a bit needed there | 12:20 |
| tristan | tlater, maybe, if it's unclear; the roles are currently a bit mixed... the reflection I had when last looking at the scheduler and fixing it for private data was this: | 12:21 |
| tristan | I asked myself: Hmmmm, Queue.active_jobs member is public, that sucks | 12:21 |
| tristan | The Queues currently handle the callbacks of complete jobs, and ask the scheduler to retrigger stuff as a result | 12:22 |
| tristan | and the scheduler has to look deep into the Queue's private details for the purpose of suspend and terminate mostly | 12:22 |
| tristan | tlater, however you could equally be right and I could be looking at this backwards | 12:22 |
| tlater | So, this may be crazy talk, but could we consider moving what the queues do to jobs? | 12:23 |
| tristan | tlater, what we want to avoid, is another _pipeline.py disaster | 12:23 |
| tlater | Now that the Jobs interface is abstract anyway, we can have things like TrackJob instead of a generic element job | 12:24 |
| tlater | And have the scheduler sort out in which order jobs have to be run | 12:24 |
| tristan | I dont want to lose queues here | 12:24 |
| tristan | Queues are required, especially the moving of elements from one to another | 12:24 |
| tristan | However, abstracting the custom work in Job subclasses instead of Queue subclasses might be alright | 12:25 |
| tristan | I'm not sure what it buys us, but you might know what it buys us | 12:25 |
| tlater | tristan: My concern has been with how we know what manages jobs submitted to anything that's not a queue | 12:26 |
| tristan | Right | 12:26 |
| tlater | Because are growing jobs that aren't part of a specific queue | 12:26 |
| tristan | It might be that queues become things which the scheduler asks to produce jobs | 12:27 |
| tristan | I.e. "Do you have any more jobs for me ?" | 12:27 |
| tristan | let's run em' | 12:27 |
| tristan | Instead of letting the Queue objects manage a list of "active_jobs" | 12:28 |
| tristan | tlater, that would significantly impact how retries are managed, note. | 12:28 |
| * tlater doesn't see why here | 12:29 | |
| tlater | Currently the jobs figure out how many times/how they are retried | 12:30 |
| tristan | I think that Queues currently retain their processing "token" until the retries are up, and relaunches jobs itself | 12:30 |
| tristan | Do they ? | 12:30 |
| tristan | Ah tlater, you are right | 12:30 |
| tristan | slipped my mind | 12:30 |
| tristan | that's convenient yes | 12:31 |
| tristan | I think the bigger question is how side effects are managed | 12:31 |
| tlater | Well, with this approach of asking the queues what to do I think that's answered too | 12:32 |
| tristan | So you have the Scheduler asking the queues for jobs... and... we know that in every circumstance where we might scheduler additional jobs, it's a result of a queue activity | 12:32 |
| tlater | Because in essence, the queues will just have to also submit a different kind of job | 12:32 |
| tristan | tlater, good point, at face value this sounds good | 12:32 |
| tristan | I think that changing the Queue specifics to Job specifics is an unnecessary change | 12:34 |
| tlater | Perhaps, but looking at the result of making jobs abstract, it just seems odd that queues still manage what the jobs *do* | 12:34 |
| tristan | It might amount to the same thing, either way... specific Queue implementations which use ElementJob Jobs, or one Queue implementation which uses different ElementJob subclasses | 12:35 |
| *** toscalix has quit IRC | 12:35 | |
| *** toscalix has joined #buildstream | 12:36 | |
| tristan | Hmmm | 12:36 |
| tristan | tlater, seems like a good point | 12:36 |
| tristan | tlater, I wonder if the Queue has more context available than a Job, but I guess not; in one sense though there is a difference | 12:37 |
| tristan | The difference being that, A.) The queue has some measure of control on "what happens next"... and B.) The queue produces side effects in the main process data model | 12:37 |
| tristan | If we move that to Job only, then Job might only be able to do (B), it's unclear if it needs more control in terms of (A) | 12:38 |
| tristan | At least we know that Jobs always complete in the main process and produce serialized side effects (i.e. not concurrent) | 12:38 |
| tlater | tristan: If you consider the queue class that wraps the jobs their manager it still has control over "what happens next" | 12:39 |
| tlater | I'm just unsure where to go with the multiple queues - they are still necessary at least for the frontend | 12:40 |
| * tlater takes a look at this in code and will come back with questions once there's a bit more of a concrete implementation | 12:44 | |
| tristan | tlater, we might want a single "queue manager" thing which we give to the scheduler, which itself consumes the concept of job tokens and moving elements through queues | 12:48 |
| tristan | tlater, remember also that if the scheduler asks the queues (or queue manager) for jobs, it has to also give them back when they complete | 12:49 |
| tristan | the flow for the scheduler might be: A.) Wake up when a job completes... B.) Give the job back... C.) Ask for more jobs... D.) Run jobs... E.) Sleep | 12:51 |
| tristan | Where it originally starts at (C) in Scheduler.run() | 12:52 |
| tlater | tristan: If we remove the specialization from the queues, do they essentially become lists, or am I missing something? | 12:52 |
| tristan | The token consumption | 12:53 |
| tristan | lemme check | 12:53 |
| tlater | That is already managed by the queue manager in my implementation, I think | 12:53 |
| tlater | Oh, no, it's managed by the generic queue class, ah! | 12:53 |
| tlater | Hm, that's lists with a purpose attached | 12:54 |
| * tlater thinks the manager could handle this better | 12:54 | |
| tristan | Yes | 12:54 |
| tristan | Well I dont know, the manager might become quite complex; it could still do with a Queue class to separate some logic | 12:54 |
| tristan | tlater, also, they would gain the knowledge of which kind of Job to spawn | 12:56 |
| * tlater doesn't like the idea of making classes purely to be an enum | 12:57 | |
| tristan | tlater, so with a shift like this, you might have a generic Queue() object with A.) The bookkeeping, including action names and failed/processed/skipped elements | 12:57 |
| tristan | B.) The way type of the Job to launch | 12:57 |
| tristan | tlater, they might be simple classes... we prefer those as they are more coherently readable than dictionaries | 12:58 |
| tristan | I.e. it might be one simple Queue class that takes it's token type, action name and job type as a constructor | 12:58 |
| tlater | Hm, well, this is a detail anyway, this can be changed if it seems too simple | 12:59 |
| * tlater has a look at whether he can get to this architecture in the first place | 12:59 | |
| tristan | tlater, I'm still a bit skeptical here about making that shift to be honest | 13:00 |
| tristan | the more I think about it | 13:00 |
| tristan | Queues need to implement Queue.status() | 13:00 |
| tristan | which tells if an element should wait, be skipped, or is ready | 13:00 |
| tristan | which informs the processing loop which pulls elements through queues | 13:00 |
| tristan | tlater, if we were to move that to specific ElementJob() subclasses, the job implementations seem to do more than just a the job | 13:01 |
| tlater | Hm, that's true | 13:01 |
| tristan | also those properties would not be shared by non-element-processing jobs | 13:01 |
| tristan | I think that a queue manager would still be a good idea, the remove some of the burden from Scheduler | 13:04 |
| tristan | the tokens and the loop which moves elements through queues | 13:04 |
| tristan | and maybe have the scheduler manage the active jobs itself | 13:05 |
| tlater | I still like the idea of asking the queues for jobs | 13:05 |
| tristan | just proxying the job completion callbacks back through the manager and to their respective queues | 13:05 |
| tristan | Right, that's pretty much what I'm saying | 13:06 |
| tlater | Yep, that seems fine | 13:06 |
| tristan | If we get this all into a queue manager, we could implement that flow in the scheduler | 13:06 |
| tristan | Also, we could implement side effects outside of the scheduler | 13:07 |
| tristan | (in the form of additional jobs becoming available for processing) | 13:07 |
| *** gokcennurlu has joined #buildstream | 13:56 | |
| gokcennurlu | hi all! | 13:56 |
| gokcennurlu | I have a question about the cleanup part in bubblewrap-sandbox, specifically here: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/sandbox/_sandboxbwrap.py#L210 | 13:58 |
| gokcennurlu | In this line, shouldn't the if condition be "if existing_basedirs[basedir]" instead of "if not existing_basedirs[basedir]" | 13:59 |
| gokcennurlu | Because, buildstream prefers to preserve those directories if they already exists before bwrapping. | 14:01 |
| *** tristan has quit IRC | 14:05 | |
| *** tristan has joined #buildstream | 14:08 | |
| tristan | gokcennurlu, hmmm, you would appear to be correct :) | 14:11 |
| tristan | or no wait | 14:12 |
| tristan | confusing :) | 14:12 |
| * Nexus is interested in this also | 14:12 | |
| tristan | "if it did not exist before, we shall skip removing it" | 14:12 |
| tristan | is what we're doing | 14:12 |
| tristan | "if it did exist before, we shall skip removing it" indeed seems correct | 14:13 |
| tristan | this must have gotten lost in translation somewhere | 14:13 |
| tristan | I sort of wish bubblewrap would take care of this part | 14:14 |
| tristan | or wait... no | 14:16 |
| gokcennurlu | To clarify, "we should clean it, only it was created during/in/due to bubblewrap" | 14:16 |
| tristan | yes, the double negative is a bit maddening | 14:17 |
| gokcennurlu | and "Not do anything, if they already exist just before we start bwarp - because maybe user wants to keep them around" | 14:17 |
| tristan | So, a good thing would be to add an integration test using the alpine image | 14:18 |
| tristan | if the image contains one of those dirs, we could use a self transforming script element to test it | 14:18 |
| gitlab-br-bot | buildstream: merge request (jjardon/debian-9->master: WIP: .gitlab-ci.yml: Run test in current Debian stable (stretch)) #425 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/425 | 14:19 |
| tristan | and assert that existing directories dont get removed from a self transformation script | 14:19 |
| tristan | I think that you are right that 'not' needs to be removed, though | 14:19 |
| gokcennurlu | got it :) | 14:19 |
| gokcennurlu | should I create an issue, than maybe a MR with that fix + integration test? | 14:20 |
| tristan | gokcennurlu, that would be great :) | 14:20 |
| gokcennurlu | will do, thank you | 14:20 |
| cs_shadow | tlater: just fyi ^^^ was the thing that was causing the "bug" I mentioned earlier | 14:21 |
| tlater | cs_shadow: Ah, right, that was resolved pretty quickly then :) | 14:23 |
| cs_shadow | tlater: yeah, and our base image was also wrong in the sense that it shouldn't have had those dirs in the first place but it was kinda good that I messed up that part. As we won't have noticed this bug otherwise :) | 14:24 |
| tristan | cs_shadow, :) | 14:25 |
| tristan | nice catch | 14:25 |
| gitlab-br-bot | buildstream: merge request (tristan/separate-junction-refs->master: Separate junction refs) #434 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/434 | 14:42 |
| tristan | grrr gitlab | 15:08 |
| tristan | https://gitlab.com/BuildStream/buildstream/pipelines/21079144 says it's running... https://gitlab.com/BuildStream/buildstream/-/jobs/64972890 says it's done | 15:09 |
| * tristan wants to slap the tv set and see a clearer image | 15:09 | |
| tlater | tristan: ctl+f5 sometimes helps | 15:09 |
| tlater | I think they handle client-side caching poorly | 15:10 |
| tlater | So browsers end up showing outdated content | 15:10 |
| tristan | oh well would you look at that | 15:10 |
| tristan | gitlab still thinks the pipeline is running though | 15:11 |
| tristan | even will all jobs green | 15:11 |
| tlater | Hm, odd | 15:11 |
| tristan | I'm quite annoyed that my actual code change did not make *any* change in code quality though :-S | 15:12 |
| tristan | https://gitlab.com/BuildStream/buildstream/merge_requests/434 | 15:12 |
| tristan | " No changes to code quality " | 15:13 |
| tristan | you'd think that some code changes would have changed *something*, and not be *exactly* the same | 15:13 |
| tristan | we'll have to see, if we make vast changes to the codebase and the quality never changes, I'm backing out the job :) | 15:14 |
| tristan | hmmm this looks interesting https://www.pydoc.io/pypi/radon-2.0.3/autoapi/cli/tools/index.html#cli.tools.cli.tools.dict_to_codeclimate_issues | 15:16 |
| dominic | how does it determine code quality ooi? | 15:21 |
| tristan | dominic, so gitlab decided to hard code another feature instead of letting us just do what we want | 15:22 |
| tristan | it understands a codeclimate.json | 15:22 |
| tristan | which is a thing that codeclimate framework generates | 15:22 |
| tristan | Apparently, there are a bunch of plugins, and radon is one of them | 15:22 |
| tristan | but, we just use this black box which gitlab gives us, so we have know clue whatsoever if it works at all | 15:23 |
| tristan | we're just trying it | 15:23 |
| tristan | at the same time, we *actually run radon* already | 15:23 |
| dominic | ahh, OK | 15:24 |
| tristan | So hopefully, we could feed the `radon cc` results, converted into a codeclimate.json, and circumvent the whole annoying framework which stands in between radon and the results understood by gitlab | 15:24 |
| gitlab-br-bot | buildstream: issue #379 ("_sandboxbwrap.py: Post-bwrap cleanup shouldn't attempt to remove preexisting folders") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/379 | 15:43 |
| *** noisecell has quit IRC | 15:53 | |
| *** noisecell has joined #buildstream | 15:59 | |
| gitlab-br-bot | buildstream: merge request (jjardon/debian-9->master: .gitlab-ci.yml: Run test in current Debian stable (stretch)) #425 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/425 | 16:00 |
| *** cs_shadow has quit IRC | 16:01 | |
| *** cs_shadow has joined #buildstream | 16:01 | |
| *** Prince781 has joined #buildstream | 16:04 | |
| *** bethw has quit IRC | 16:07 | |
| gitlab-br-bot | buildstream: merge request (jennis/136-clean-remote-cache->master: WIP: jennis/136 clean remote cache) #421 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/421 | 16:08 |
| gitlab-br-bot | buildstream: merge request (jennis/136-clean-remote-cache->master: WIP: jennis/136 clean remote cache) #421 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/421 | 16:08 |
| gitlab-br-bot | buildstream: merge request (jennis/136-clean-remote-cache->master: WIP: jennis/136 clean remote cache) #421 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/421 | 16:08 |
| gitlab-br-bot | buildstream: merge request (jjardon/dependencies->master: .gitlab-ci.yml: Remove redundant declaration of dependencies:) #435 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/435 | 16:08 |
| gitlab-br-bot | buildstream: merge request (jjardon/another_codequality->jjardon/codequality: WIP: test codequality) #432 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/432 | 16:10 |
| *** jonathanmaw has quit IRC | 16:11 | |
| valentind | Are there any project where bzr is used as source plugin? | 16:13 |
| gitlab-br-bot | buildstream: merge request (jjardon/debian-9->master: .gitlab-ci.yml: Run test in current Debian stable (stretch)) #425 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/425 | 16:14 |
| tristan | valentind, it was originally added to ensure that we can support any conversion from flatpak builder json | 16:14 |
| gitlab-br-bot | buildstream: merge request (jennis/136-clean-remote-cache->master: WIP: jennis/136 clean remote cache) #421 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/421 | 16:14 |
| tristan | valentind, if it's not used in freedesktop-sdk, I dont have a current example | 16:14 |
| gitlab-br-bot | buildstream: merge request (jjardon/debian-9->master: .gitlab-ci.yml: Run test in current Debian stable (stretch)) #425 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/425 | 16:15 |
| tristan | (but it's certainly required in order to support flatpak-builder json conversion safely) | 16:15 |
| valentind | Also I am not familiar with bazaar. But I thought that there was one URL per branch. Though the plugin seems to use the "track" configuration. I am not sure why it is needed to track. | 16:15 |
| gitlab-br-bot | buildstream: issue #361 ("Store junction refs separately to project.refs") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/361 | 16:15 |
| gitlab-br-bot | buildstream: merge request (jennis/136-clean-remote-cache->master: WIP: jennis/136 clean remote cache) #421 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/421 | 16:15 |
| gitlab-br-bot | buildstream: issue #361 ("Store junction refs separately to project.refs") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/361 | 16:15 |
| gitlab-br-bot | buildstream: merge request (tristan/separate-junction-refs->master: Separate junction refs) #434 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/434 | 16:15 |
| valentind | tristan, OK. So it could be that the plugin is not mature? | 16:16 |
| tristan | valentind, you might talk to jonathanmaw about that, he wrote the plugin, but seems to be absent | 16:16 |
| tristan | well, it's just as aggressively tested as the rest, I should hope that it works very well | 16:16 |
| gitlab-br-bot | buildstream: merge request (jjardon/dependencies->master: .gitlab-ci.yml: Remove redundant declaration of dependencies:) #435 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/435 | 16:16 |
| gitlab-br-bot | buildstream: merge request (jjardon/debian-9->master: .gitlab-ci.yml: Run test in current Debian stable (stretch)) #425 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/425 | 16:18 |
| gitlab-br-bot | buildstream: merge request (jjardon/debian-9->master: .gitlab-ci.yml: Run test in current Debian stable (stretch)) #425 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/425 | 16:18 |
| gitlab-br-bot | buildstream: merge request (jjardon/debian-9->master: .gitlab-ci.yml: Run test in current Debian stable (stretch)) #425 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/425 | 16:19 |
| gitlab-br-bot | buildstream: merge request (jjardon/dependencies->master: .gitlab-ci.yml: Remove redundant declaration of dependencies:) #435 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/435 | 16:19 |
| tristan | ok tomorrow is release day I think | 16:24 |
| tristan | time to update freedesktop-sdk and gnome-build-meta to use ninja for cmake, and start revisioning junction.refs in gnome-build-meta | 16:25 |
| *** Prince781 has quit IRC | 16:27 | |
| *** dominic has quit IRC | 17:09 | |
| *** dominic has joined #buildstream | 17:12 | |
| *** toscalix has quit IRC | 17:19 | |
| *** dominic has quit IRC | 17:31 | |
| jjardon | tristan: \o/ | 17:32 |
| jjardon | tristan: MR for those are ready and waiting for the release | 17:32 |
| *** Prince781 has joined #buildstream | 17:42 | |
| *** Prince781 has quit IRC | 17:55 | |
| tristan | yeah the timing is right for a 1.1.3, we're quite stable | 17:58 |
| tristan | wanna do it before landing anything questionable | 17:59 |
| * tristan hopes 1.1.4 is a release concentrated on artifact expiry | 18:00 | |
| tristan | or at least remote expiry | 18:00 |
| jjardon | double \o/ :) | 18:02 |
| gitlab-br-bot | buildstream: merge request (jjardon/debian-9->master: .gitlab-ci.yml: Run test in current Debian stable (stretch)) #425 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/425 | 18:13 |
| *** valentind has left #buildstream | 18:20 | |
| *** valentind has joined #buildstream | 18:21 | |
| *** xjuan has joined #buildstream | 18:25 | |
| *** Prince781 has joined #buildstream | 18:37 | |
| *** Prince781 has quit IRC | 19:20 | |
| *** Prince781 has joined #buildstream | 19:26 | |
| *** Prince781 has quit IRC | 19:31 | |
| *** cs_shadow has quit IRC | 19:41 | |
| *** xjuan has quit IRC | 19:51 | |
| *** tristan has quit IRC | 20:27 | |
| *** gokcennurlu has quit IRC | 21:27 | |
| *** aday has quit IRC | 21:40 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!