| *** mohan43u has quit IRC | 03:33 | |
| *** mohan43u has joined #buildstream | 03:37 | |
| *** mohan43u has quit IRC | 06:19 | |
| *** mohan43u has joined #buildstream | 06:19 | |
| *** noisecell has joined #buildstream | 06:45 | |
| *** Prince781 has quit IRC | 07:04 | |
| *** tristan has joined #buildstream | 07:10 | |
| *** mohan43u has quit IRC | 07:17 | |
| *** toscalix has joined #buildstream | 07:36 | |
| *** toscalix has quit IRC | 07:41 | |
| *** mohan43u has joined #buildstream | 07:42 | |
| *** toscalix has joined #buildstream | 07:50 | |
| *** aday has joined #buildstream | 08:07 | |
| *** toscalix has quit IRC | 08:11 | |
| *** toscalix has joined #buildstream | 08:17 | |
| *** toscalix has quit IRC | 08:31 | |
| *** valentind has quit IRC | 08:39 | |
| *** aday has quit IRC | 08:53 | |
| *** aday has joined #buildstream | 09:04 | |
| *** tiago has joined #buildstream | 09:05 | |
| *** Nexus has joined #buildstream | 09:11 | |
| *** dominic has joined #buildstream | 09:21 | |
| *** bethw has joined #buildstream | 09:23 | |
| *** noisecell has quit IRC | 09:31 | |
| *** noisecell has joined #buildstream | 09:31 | |
| *** dominic has quit IRC | 09:52 | |
| *** dominic has joined #buildstream | 09:58 | |
| laurence | Nexus, hello | 10:01 |
|---|---|---|
| Nexus | hello laurence | 10:01 |
| laurence | :) | 10:01 |
| Nexus | :) | 10:01 |
| Nexus | i'm glad we had this little chat | 10:01 |
| laurence | so we were chatting about this - https://wiki.codethink.co.uk/bl013/log/standup-20180326/ and also https://gitlab.com/BuildStream/buildstream/issues/319 | 10:01 |
| laurence | woops, wrong link | 10:02 |
| * Nexus assumes you meant https://gitlab.com/BuildStream/buildstream/issues/317 | 10:02 | |
| laurence | yes | 10:02 |
| Nexus | so it looks like 317 is mostly directed at me, since it directly changes the functionality i wrote | 10:02 |
| Nexus | it seems like a simple fix | 10:02 |
| Nexus | issue 319, i'm not sure about, i COULD look at it, but it seems more of a generalised issue | 10:02 |
| juergbi | 317 is already closed | 10:03 |
| laurence | I *think* that simple fix might have been solved over the weekend - juergbi and tristan landed some MRs, but I'm not sure which aspects were carried over into #319 | 10:03 |
| juergbi | the second point in #317 is fixed | 10:04 |
| juergbi | the first point is generalized into #319 | 10:04 |
| Nexus | ah i see | 10:04 |
| juergbi | i.e., the urgent issue is fixed | 10:04 |
| laurence | alright, thanks, sorry for the noise! | 10:05 |
| Nexus | but the try/except one isnt | 10:05 |
| Nexus | laurence: Should i look at #319? | 10:05 |
| laurence | well i was wondering if you were well placed to pick it up, so was asking you, but i don't think it's worth disrupting current tasks for, persoanlly | 10:07 |
| Nexus | ok, if it isn't resolved when i'm done with my current task, i'll pick it up | 10:07 |
| Nexus | is tristan around? | 10:09 |
| Nexus | juergbi: i'm donig something potentially ugly, but it prevents something worse, and i wanted a second opinion on it | 11:03 |
| juergbi | Nexus: ok, please elaborate | 11:04 |
| Nexus | Option A) @click.option('--no-cache', 'cache', default=True, is_flag=False), so having no cache set the value to false. OR Option B) later on do a "If not no-cache" | 11:05 |
| *** mohan43u has quit IRC | 11:05 | |
| juergbi | Nexus: can't you follow the approach taken by --debug/--colors/--strict? | 11:07 |
| Nexus | so have no default? | 11:08 |
| juergbi | I think you can still have default=True | 11:08 |
| juergbi | but use --cache/--no-cache | 11:08 |
| *** mohan43u has joined #buildstream | 11:09 | |
| juergbi | that said, I'm skeptical of a --no-cache CLI option | 11:09 |
| Nexus | was tristans idea IIRC | 11:09 |
| juergbi | any reference? here on IRC, on gitlab or where? | 11:10 |
| juergbi | I might be missing context | 11:10 |
| Nexus | gimme a min | 11:10 |
| Nexus | https://gitlab.com/BuildStream/buildstream/issues/311 | 11:11 |
| Nexus | tristans comment | 11:11 |
| Nexus | how do you link a comment? | 11:11 |
| juergbi | the time in the comment header is a link | 11:12 |
| juergbi | ah, this is a workspace specific option | 11:12 |
| juergbi | I was somehow thinking about a global/build option about caching build directories | 11:12 |
| juergbi | that makes more sense | 11:12 |
| Nexus | ah kk | 11:13 |
| Nexus | and ty | 11:13 |
| Nexus | juergbi: does your comment still apply? 12:07 <juergbi > Nexus: can't you follow the approach taken by --debug/--colors/--strict? | 11:14 |
| juergbi | yes, I don't see anything speaking against a flag option | 11:15 |
| juergbi | btw: of the two original suggestions, I would have chosen B | 11:15 |
| juergbi | (A) would be way too misleading | 11:15 |
| juergbi | for (B) you could also have something like cache = not no-cache right at the beginning of the function | 11:16 |
| Nexus | but ew double negatives | 11:16 |
| juergbi | yes but better than completely incorrect variable name | 11:16 |
| juergbi | anyway, flag option should avoid the issue | 11:17 |
| juergbi | ah, that wouldn't have actually been the case | 11:18 |
| juergbi | I'm still not that used to click syntax | 11:18 |
| milloni | can someone assign me to https://gitlab.com/BuildStream/buildstream/issues/289 please? I'm going to tackle that | 11:23 |
| juergbi | so option (A) would actually be fine as well as click is smart enough to handle boolean with default True | 11:23 |
| tristan | milloni, did you request developer access to the project ? if you do - it will be approved; and you can easily self assign it | 11:25 |
| milloni | tristan, i'll do that, thanks | 11:25 |
| *** noisecell has quit IRC | 11:26 | |
| *** noisecell has joined #buildstream | 11:26 | |
| tlater | Our artifacts currently get ostree refs like these: '{0}/{1}/{2}'.format(project.name, element_name, key) | 11:38 |
| tlater | Is there any way to serialize that back into element names? | 11:39 |
| tlater | *element objects | 11:39 |
| tlater | I understand that some of these will be missing, but I need to figure out which artifacts are going to be used in the current pipeline | 11:39 |
| tlater | Hm, actually, maybe this can be done the other way around... | 11:41 |
| tlater | That brings up another issue - can we standardize this serialization between different artifact cache implementations? | 11:45 |
| tlater | ATM it happens to be the same format, but I'll have to start relying on the ref being the same across implementations | 11:46 |
| juergbi | tlater: yes, I want to move that logic out of the artifact cache-specific implementation | 11:50 |
| tlater | juergbi: looks like we use serialized element names as well - I don't think these can be turned back because the actual name might contain dashes, but this converts path separators to dashes :[ | 11:56 |
| juergbi | tlater: we should probably not change the name for YAML serialization | 12:01 |
| juergbi | we don't guarantee stability for metadata, afaik, so we can change that (but have to bump the artifact version) | 12:01 |
| jmac | Is there any chance of increasing my access to the Buildstream repo so I can examine the CI settings? I'm currently developer and think I will need master/owner. | 12:03 |
| tlater | Oh no, jmac is going to figure out all our secret keys! | 12:05 |
| * tlater elevated jmac to master | 12:05 | |
| Nexus | isnt thaty what the yaml is for? | 12:06 |
| tlater | Nexus: jmac wants to set up a runner, the yaml can't do that | 12:08 |
| * Nexus is the only one not master | 12:08 | |
| * tlater sees a lot of developers on the members page | 12:09 | |
| jmac | Thanks tlater | 12:21 |
| tlater | Hm, just to confirm; are weak keys only used if we're building with --no-strict? | 12:26 |
| *** toscalix has joined #buildstream | 12:26 | |
| juergbi | tlater: almost | 12:28 |
| juergbi | tlater: refs for weak cache keys are also created when building with --strict | 12:28 |
| juergbi | they are never used via lookup, though | 12:29 |
| juergbi | that's done only to allow switching from --strict to --no-strict reusing artifacts | 12:29 |
| juergbi | (or having strict build server and no-strict client) | 12:29 |
| tlater | juergbi: Would we want to keep that behavior when we're running out of space in the cache? | 12:29 |
| * tlater thinks about only locking strict/weak keys depending on the build mode used | 12:30 | |
| juergbi | i think expiry should be independent of the current mode | 12:30 |
| tlater | I suppose it doesn't really affect what's in the cache in the strict case, though | 12:30 |
| tlater | Yeah, locking both keys seems more sensible, because it probably won't affect the actual size in most cases. | 12:31 |
| juergbi | we should avoid deleting a weak cache key ref if we don't also delete the corresponding strict cache key ref | 12:31 |
| juergbi | as that won't save any space anyway | 12:31 |
| juergbi | if that's not too complex | 12:32 |
| tlater | juergbi: No, it's actually easier because you don't have to reference the pipeline from a class that usually can't reference it ;) | 12:33 |
| juergbi | good | 12:33 |
| *** xjuan has joined #buildstream | 13:15 | |
| gitlab-br-bot | buildstream: issue #321 ("It should be possible to overlap elements already present in a junction") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/321 | 13:36 |
| *** tristan has quit IRC | 14:04 | |
| *** tristan has joined #buildstream | 14:07 | |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 14:09 |
| *** alatiera has joined #buildstream | 14:17 | |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 14:28 |
| *** mohan43u has quit IRC | 15:06 | |
| gitlab-br-bot | buildstream: issue #89 ("Absolute build directories should be unique per element") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/89 | 15:07 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: Made modification to generate unique subdirs for built elements) #310 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 15:07 |
| *** mohan43u has joined #buildstream | 15:10 | |
| *** noisecell has quit IRC | 15:27 | |
| jennis | Ok, having problems with: `make -C doc` because of this arpy installation | 15:42 |
| jennis | https://paste.baserock.org/axiyuwafew | 15:42 |
| jennis | *importation | 15:42 |
| juergbi | jennis: hm, is there an issue considering arpy a requirement for doc generation? | 15:43 |
| juergbi | I didn't realize that doc generation actually imports modules | 15:44 |
| juergbi | I was expecting them to get scanned without importing | 15:44 |
| tlater | pylint also seems to complain because it can't figure out that the module is never called if arpy isn't installed | 15:44 |
| tlater | Though that can probably be fixed with a # pylint: disable= | 15:45 |
| gitlab-br-bot | buildstream: merge request (jennis/correct-installing-documentation->master: install.rst: Modify how we tell a user to adjust their path) #340 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/340 | 15:49 |
| jennis | Seems that way juergbi, I'm not yet sure how to fix this | 15:51 |
| juergbi | jennis: without installing arpy, you mean? it shouldn't block anyone | 15:51 |
| jennis | I am also getting this error, and I'm up to date with master: https://paste.baserock.org/ukowasofox | 15:51 |
| jennis | Yes without installing arpy | 15:52 |
| jennis | The latter error probably just needs a `# pylint: disable=import-error` as tlater suggested | 15:52 |
| juergbi | should probably add notes to this https://gitlab.com/BuildStream/buildstream/issues/319 | 15:53 |
| jennis | ok, so we're saying the only way round is to install arpy? | 15:55 |
| jennis | also juergbi what do you think about disabling the pylint warning to the import? | 15:56 |
| juergbi | for doc generation this may be acceptable, but ideally we can avoid it | 15:57 |
| juergbi | for pylint we should fix it | 15:57 |
| juergbi | jennis: do you know whether we can use something like conditional skip if not HAVE_ARPY for the whole deb.py file for pylint? | 15:58 |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: WIP: Print summary of failed builds) #329 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 15:58 |
| tlater | juergbi: I don't think that's possible, but I don't think it would be useful either | 15:59 |
| juergbi | explicit pylint import-error is definitely also an option if that doesn't cause any other issues | 15:59 |
| * juergbi wonders why we don't see the issue for gi/ostree in unix-tests pylint | 16:00 | |
| tlater | There's no point in checking whether we have an import error if we know the module is installed | 16:00 |
| tlater | And if we know that an import error may occur if it isn't... | 16:00 |
| juergbi | if there are no other side effects, yes | 16:01 |
| juergbi | just don't want to see some unknown member error because of the ignored import | 16:01 |
| juergbi | tlater: any idea about gi/ostree? | 16:02 |
| tlater | That doesn't happen afaik, jennis will presumable see in a minute :) | 16:02 |
| tlater | juergbi: Where should this happen with ostree? | 16:02 |
| juergbi | ostree source | 16:02 |
| tlater | Ah, right | 16:02 |
| juergbi | or rather _ostree.py helper | 16:02 |
| tlater | I suspect nobody has attempted running it without ostree | 16:03 |
| tlater | Ah | 16:03 |
| tlater | That's a bug in CI then | 16:03 |
| juergbi | I thought you explicitly remove ostree, that's why you use Fedora in the pending MR? | 16:03 |
| tlater | Yep, that's what I thought | 16:03 |
| tlater | Is pylint not covered by it somehow? | 16:03 |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: WIP: Print summary of failed builds) #329 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 16:04 |
| juergbi | maybe we still have pygobject installed, so the real import is still covered? | 16:04 |
| juergbi | ideally, we would remove that as well | 16:04 |
| tlater | Yep, I'll file an issue and try to merge it as part of the !266 MR | 16:04 |
| * tlater wanted to make some progress on #135 while his mind is fresh on it before getting to those MRs | 16:04 | |
| juergbi | ok, ta | 16:05 |
| gitlab-br-bot | buildstream: issue #322 ("Pylint should probably complain about our ostree imports in CI") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/322 | 16:08 |
| jennis | tlater, not sure if this could be any use: https://gitlab.com/BuildStream/buildstream/blob/master/.pylintrc#L195 | 16:12 |
| tlater | juergbi: ^ That might actually be related, yes. Though I'll definitely test uninstalling pygobject in the unix case. | 16:14 |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: WIP: Print summary of failed builds) #329 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 16:24 |
| gitlab-br-bot | buildstream: merge request (jennis/correct-installing-documentation->master: install.rst: Modify how we tell a user to adjust their path) #340 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/340 | 16:34 |
| *** jonathanmaw has joined #buildstream | 16:36 | |
| gitlab-br-bot | buildstream: merge request (jennis/correct-installing-documentation->master: install.rst: Modify how we tell a user to adjust their path) #340 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/340 | 16:41 |
| gitlab-br-bot | buildstream: merge request (jennis/correct-installing-documentation->master: install.rst: Modify how we tell a user to adjust their path) #340 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/340 | 16:41 |
| *** bethw has quit IRC | 16:48 | |
| gitlab-br-bot | buildstream: merge request (jennis/correct-installing-documentation->master: install.rst: Modify how we tell a user to adjust their path) #340 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/340 | 16:50 |
| gitlab-br-bot | buildstream: merge request (jmac/performance-ci->master: WIP: .gitlab-ci.yml: Add the performance test.) #341 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/341 | 16:54 |
| jmac | ^ that's a MR which adds benchmarking to our usual CI. As I've said in the issue, it means we rely on one specific runner currently at Codethink, which isn't great. Any ideas on what we could do to make it more accessible? | 16:58 |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: Print summary of failed builds) #329 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 17:11 |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: Print summary of failed builds) #329 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 17:13 |
| *** dominic has quit IRC | 17:32 | |
| *** toscalix has quit IRC | 18:05 | |
| *** valentind has joined #buildstream | 18:15 | |
| *** jonathanmaw has quit IRC | 18:17 | |
| *** jonathanmaw has joined #buildstream | 18:23 | |
| *** solid_black has joined #buildstream | 18:47 | |
| *** jonathanmaw has joined #buildstream | 20:17 | |
| *** jonathanmaw has quit IRC | 20:17 | |
| *** tristan has quit IRC | 20:48 | |
| *** solid_black has quit IRC | 20:49 | |
| *** xjuan has quit IRC | 20:58 | |
| *** aday has quit IRC | 21:04 | |
| *** valentind has quit IRC | 21:43 | |
| *** xjuan has joined #buildstream | 22:29 | |
| *** mohan43u has quit IRC | 22:37 | |
| *** mohan43u has joined #buildstream | 22:40 | |
| *** xjuan has quit IRC | 23:37 | |
| *** Prince781 has joined #buildstream | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!