IRC logs for #buildstream for Monday, 2018-05-14

*** jennis has joined #buildstream00:15
*** jennis_ has joined #buildstream00:15
*** jennis_ has quit IRC02:22
*** jennis has quit IRC02:22
*** ernestask has joined #buildstream05:02
*** noisecell has joined #buildstream05:07
*** tristan has joined #buildstream05:22
*** dominic has joined #buildstream06:52
*** noisecell has quit IRC07:36
*** toscalix has joined #buildstream07:50
*** toscalix_ has joined #buildstream07:55
*** toscalix has quit IRC07:55
*** toscalix_ has quit IRC08:03
*** toscalix_ has joined #buildstream08:05
*** finn has joined #buildstream08:08
*** bochecha_ has joined #buildstream08:24
*** finn_ has joined #buildstream08:28
*** finn has quit IRC08:30
*** toscalix has joined #buildstream08:31
*** toscalix_ has quit IRC08:33
*** jonathanmaw has joined #buildstream08:40
*** awacheux has joined #buildstream08:44
*** noisecell has joined #buildstream08:50
*** bethw has joined #buildstream08:51
juergbitlater: is there any test covering the artifact cache diff feature?09:07
tlaterjuergbi: I'm fairly sure there is, though I don't quite recall the name of the test... Hang.09:08
juergbiI thought there was as well but can't find it09:09
tlaterjuergbi: They are in integration/workspace.py09:09
tlaterThe last few tests09:09
juergbihm, right, they should cover this, wondering why this doesn't work09:10
tlaterWhat problem are you looking at? Always a chance I overlooked an edge case...09:12
juergbinever mind, I wasn't running the right tests09:12
juergbiit doesn't trigger added/removed subdirectories, afaict, but otherwise looks fine09:13
tlaterOh, right, I wanted to add a test case for that.09:13
tlaterDamnit09:13
gitlab-br-botbuildstream: merge request (juerg/googlecas->master: WIP: Google CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/33709:14
juergbijmac: the updated !337 should now pass all tests (except a CI docs issue I have to look into)09:16
juergbiit's still WIP, not ready for review, but would likely be usable as base for your branch, if you need it09:17
jmacSounds great juergbi, I'll take a look09:17
*** tiago has joined #buildstream09:25
jmacjuergbi: !445 might benefit from a quick look over from you to see if it's going in the right direction, if you have a chance09:25
juergbiindeed, planning to take a look today09:26
*** toscalix has quit IRC09:46
gitlab-br-botbuildstream: merge request (juerg/googlecas->master: WIP: Google CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/33709:48
*** aday has joined #buildstream09:55
*** cs_shadow has joined #buildstream09:57
*** toscalix has joined #buildstream10:13
gitlab-br-botbuildstream: merge request (214-filter-workspacing->master: Make workspace commands on a filter element transparently pass through to their build-dependency) #317 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/31710:31
juergbiis there a difference in Python module search path or similar in Debian 8 / Python 3.4?10:41
juergbipylint complains about missing in-tree module in CI, works fine on Debian 9 and Fedora 2710:41
cs_shadowHi. So, I have a couple of minor MRs that are awaiting review and "approval" in https://gitlab.com/BuildStream/buildstream-docker-images repository. Would anyone like to review them or should I bypass the approval process?10:44
cs_shadowtristan, jjardon: ^10:44
jonathanmawjuergbi: can you review https://gitlab.com/BuildStream/buildstream/merge_requests/317/ when you have time?10:46
juergbisure, adding it to mylist10:46
tristancs_shadow, you can go ahead and merge what you think is appropriate and correct10:48
tristancs_shadow, I know there is an "approval" feature that we dont use in the buildstream repo, you can use it in buildstream-docker-images if you like it, that is up to you :)10:48
tristanif you wanna disable it, please just disable it in the settings10:48
*** jonathanmaw has quit IRC10:49
cs_shadowtristan: thanks! I'll land these and will disable the approval feature for now. In case anyone wishes to introduce it again, we can surely discuss it then.10:50
*** tristan has quit IRC11:01
*** jonathanmaw has joined #buildstream11:06
*** bethw has quit IRC11:34
*** tristan has joined #buildstream11:48
*** tristan_ has joined #buildstream11:48
*** toscalix has quit IRC12:03
*** jennis has joined #buildstream12:31
*** jennis_ has joined #buildstream12:31
*** bethw has joined #buildstream12:44
gitlab-br-botbuildstream: merge request (kill_element_normal_name->master: Removed element.normal_name. (#288)) #465 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/46513:19
*** xjuan has joined #buildstream13:20
gitlab-br-botbuildstream: merge request (kill_element_normal_name->master: WIP: Removed element.normal_name. (#288)) #465 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/46513:41
tristan_hmmm, I keep meaning to say something about that13:45
finn_What would you call a name without an extension? At the moment self.name == "x.bst"13:55
finn_in element.py13:55
finn_Would you call x a name_prefix?13:57
tristan_finn_, honestly, if we're going to replace normal_name with something else, it's not worth changing anything at all14:01
tristan_I felt like calling a halt to this crusade against normal_name while it was assigned to milloni... but didnt get around to it14:02
tristan_I think I was maybe overdoing it there14:02
tristan_(with the crusade against normal_name)14:02
finn_Agreed14:02
valentindtristan_, I suppose that tracking element cross junctions should always be done in project.refs.14:03
valentindI am trying to write tests for cross junction names for "track".14:03
tristan_valentind, yes, and it currently does, I think there are regression tests for that too14:03
finn_You end up having "x.bst" running throughout the code and end up a) removing the extension or b) creating a new "element.name_prefix" variable14:04
tristan_valentind, there are early exits which ensure that the project uses project.refs if tracking was requested to cross junction boundaries14:04
finn_tristan_, shall I close the issue and abandon?14:04
tristan_valentind, for explicit `bst track junction.bst:element.bst` calls, I think those early checks need to be rethought, or ensured to still work14:04
tristan_finn_, I agree to close and abandon14:05
gitlab-br-botbuildstream: issue #288 ("Kill Element.normal_name variable") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/28814:05
gitlab-br-botbuildstream: merge request (kill_element_normal_name->master: WIP: Removed element.normal_name. (#288)) #465 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/46514:05
tristan_valentind, also, I think that if a cross junction element was explicitly specified, I think that should probably... imply `-J` ?14:06
valentindYes, I see.14:07
tristan_valentind, i.e. we already specified a cross junction element, should it be implied that we intend to cross junction boundaries and the user should *not* have to specify -J ?14:07
tristan_I think so14:07
tristan_But...14:07
tristan_What if we are doing multiple targets... --deps all14:07
tristan_and one of them is not cross junction14:07
tristan_I think the buck should still stop in recursion unless -J was specified14:07
tristan_i.e. that is "Crossing the junction boundary"14:07
tristan_not "specifying a cross junction element specifically"14:07
*** toscalix has joined #buildstream14:07
valentindI am not sure is actually needed. It is only for dependencies.14:08
valentindR14:08
valentindRight?14:08
tristan_Right, so I think that means we agree14:08
tristan_I.e. crossing junction boundaries is only about recursion14:08
tristan_valentind, however, that probably also means sub-sub project recursion now14:08
valentindAt least it looks like working without -J14:09
valentindNo, actually it fails.14:09
tristan_i.e. you can specify to recursively track junction.bst:element.bst14:09
valentindOK, so I will fix that.14:09
tristan_now without -J, you probably dont want to recurse into *that* junction.bst project dependencies14:09
tristan_there are a small hand full of edge cases to think about there and define policy for14:09
*** laurence is now known as ltu14:20
*** finn_ has quit IRC14:22
*** finn has joined #buildstream14:22
*** noisecell has quit IRC14:56
*** tristan_ has quit IRC15:03
*** bethw has quit IRC15:08
*** bethw has joined #buildstream15:09
*** noisecell has joined #buildstream15:09
*** noisecell has quit IRC15:19
*** toscalix has quit IRC15:37
*** jennis_ has quit IRC15:53
*** jennis has quit IRC15:53
*** jennis has joined #buildstream15:58
*** jennis_ has joined #buildstream15:58
*** zilbermanka has quit IRC16:06
*** tristan_ has joined #buildstream16:12
*** jennis has quit IRC16:26
*** jennis_ has quit IRC16:26
*** toscalix has joined #buildstream16:28
*** bethw has quit IRC16:31
*** tristan_ is now known as tristan16:32
*** toscalix_ has joined #buildstream16:50
*** toscalix has quit IRC16:51
gitlab-br-botbuildstream: merge request (valentindavid/359_cross_junction_elements->master: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/45416:52
valentindtristan, I added tests for pull, push, track, build, checkout, and show for cross junction elements.16:57
valentindAre there other commands I should add tests for?16:57
finnI'm a little confused by this. I've got an element which looks like this:17:28
finnkind: autotools17:29
finnsources:17:29
finn- kind: tar17:29
finnur: some_tar.tar.gz17:30
finn s/ur/url17:30
finndirectory: /home17:30
tristanvalentind, there is fetch :)17:30
tristanvalentind, but sounds awesome \o/ :)17:31
finnShouldn't autotools be then run within the /home directory?17:31
tlaterfinn: Use some paste-* start tool, if you can, makes it a bit easier to read17:31
tristanfinn, nope17:31
tristanfinn, directory on the source, actually should not be allowed to be an absolute path afaics17:32
tristanmaybe that's a bug, should probably trigger an error17:32
tristanfinn, dont try to control an absolute path where things should happen, but if you want autotools commands (or any build element commands) to happen in a subdir of the build area, use %{command-subdir}17:33
tristansince it's common to all build elements, it's documented here: http://buildstream.gitlab.io/buildstream/buildstream.buildelement.html#module-buildstream.buildelement17:34
tristaninstead of redundantly in every build element subclass17:34
finnthanks17:34
tristancommand subdir is useful for cases like, when you build mozjs, you want to run commands in the javascript engine subdir of the mozilla source tree (for example)17:35
*** jonathanmaw has quit IRC17:48
*** toscalix_ has quit IRC18:16
*** slaf has quit IRC18:20
*** slaf has joined #buildstream18:23
*** slaf has joined #buildstream18:24
*** dominic has quit IRC18:38
*** slaf_ has joined #buildstream19:34
*** slaf_ has joined #buildstream19:34
*** slaf has quit IRC19:37
*** slaf_ is now known as slaf19:37
*** xjuan has quit IRC20:01
*** Prince781 has joined #buildstream20:01
*** Prince781 has quit IRC20:04
*** Prince781 has joined #buildstream20:06
*** aday has quit IRC20:06
*** ernestask has quit IRC20:07
*** tristan has quit IRC20:10
*** Prince781 has quit IRC20:13
*** bochecha_ has quit IRC22:44

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!