| *** Prince781 has joined #buildstream | 00:58 | |
| *** Prince781 has quit IRC | 01:55 | |
| *** Prince781 has joined #buildstream | 01:56 | |
| *** mcatanzaro has quit IRC | 03:12 | |
| *** tristan has joined #buildstream | 05:13 | |
| *** tristan has quit IRC | 05:15 | |
| *** tristan has joined #buildstream | 05:15 | |
| *** Prince781 has quit IRC | 05:35 | |
| gitlab-br-bot | buildstream: issue #285 ("Get story straight with private symbols") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/285 | 05:52 |
|---|---|---|
| gitlab-br-bot | buildstream: issue #286 ("Impossible to distinguish sandboxing errors from build errors") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/286 | 08:11 |
| juergbi | tristan: regarding the symlink sdist issue. if we have to keep working around it, i think we should at least check for accidental symlinks in CI to avoid mysterious failures | 08:20 |
| juergbi | jmac: btw: nice catch | 08:20 |
| tristan | Hmmm | 08:31 |
| tristan | juergbi, maybe a part of the regular `./setup.py test` which ensures there are no revisioned symlinks ? | 08:32 |
| tristan | Plus a CI step which runs the tests on an uninstalled buildstream from git ? | 08:32 |
| tristan | Which, would probably also be a good test anyway ? | 08:33 |
| tristan | (sans the integration part, perhaps) | 08:33 |
| * tristan doesnt like the idea of adding tests which "only happen on gitlab" | 08:33 | |
| juergbi | i think we should guarantee that the test files are the same and then we don't need to run them twice | 08:34 |
| juergbi | ideally, our dist tarball would just be git archive, as we desire for other projects as well | 08:35 |
| tristan | I'm not sure thats plausible for distribution via pip, though | 08:35 |
| juergbi | why do we actually need sdist at this point? | 08:35 |
| tristan | We need it until we switch to meson or something, and mandate real host installation | 08:36 |
| tristan | Because of the magic stuff sdist does I think | 08:36 |
| tristan | Or, maybe we dont ? | 08:36 |
| juergbi | pip locally works from git, though, doesn't it? | 08:36 |
| * tristan on crack ? | 08:36 | |
| tristan | right | 08:36 |
| juergbi | at least that's how i install it | 08:36 |
| tristan | yeah, and since we are anyway not suitable for pypa... it's probably a song and dance we dont need | 08:37 |
| tristan | juergbi, there is one reason we need it though, I feel anyway | 08:37 |
| tristan | which is accurate versioning information, to be present regardless of whether the history is there | 08:38 |
| tristan | There needs to be this distribution song-and-dance where we auto generate the version metadata which ends up in a release | 08:38 |
| tristan | and ensure that a git describe thing is appended to the base tag version | 08:39 |
| tristan | That will be true regardless of what mechanism is chosen for distribution | 08:39 |
| juergbi | right, hm | 08:39 |
| juergbi | even keeping that, it may be worth switching from sdist to something very simple (essentially git archive with the version file added) | 08:41 |
| juergbi | given that sdist has bad behavior | 08:42 |
| juergbi | (or switching to meson or so but that's a bigger change) | 08:42 |
| juergbi | although there is already !196 for meson | 08:42 |
| juergbi | i would definitely miss -e, though | 08:43 |
| tristan | Yes me too :) | 08:45 |
| tristan | Ugh... python dist mess better set aside in some way for now :-/ | 08:45 |
| tristan | then again, jhbuild requires make install on every change, I expect I'd get used to it | 08:46 |
| tristan | but -e is really nice to have | 08:46 |
| juergbi | maybe we could support running it without any installation at all | 08:47 |
| juergbi | directly from the source directory | 08:47 |
| tristan | the story is probably bigger than just this, too | 08:47 |
| tristan | Because of how we rely on setuptools for pure python dependencies | 08:47 |
| tristan | I suspect in a bright shiny future, we bundle those into our installation and guarantee what we release is exactly what we release | 08:48 |
| tristan | supporting running from source directory is one thing; but it cannot be completely self contained (we need to introspect host man page directory and where to install bash completion scripts) | 08:49 |
| juergbi | may be useful for end users but would be distro unfriendly, so should be a separate option | 08:49 |
| * tristan thinks this talk is premature | 08:50 | |
| juergbi | yes, but maybe get rid of sdist in the short term | 08:50 |
| tristan | So get rid of sdist, in favor of... a script which does the version generation ? | 08:51 |
| juergbi | yes. it doesn't sound ideal but as it's so simple and sdist doesn't support symlinks... | 08:53 |
| tristan | Yeah that could be okay | 08:53 |
| tristan | I'd keep the dist step in CI | 08:53 |
| tristan | and nuke the MANIFEST.in | 08:53 |
| juergbi | yes, that sounds fine | 08:54 |
| juergbi | we'd just fix dist, not replace it | 08:54 |
| tristan | As a side effect, it would be *nice* if we fixed `-e` such that the version info is introspected dynamically, *when* running from a git checkout | 08:55 |
| tristan | right now you only get a new `bst --version` output for every `./setup.py install` | 08:55 |
| tristan | haven't been strictly considering that a bug, but we probably should | 08:56 |
| *** benzea has quit IRC | 09:04 | |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 09:14 |
| gitlab-br-bot | buildstream: merge request (jmac/restore-brackets-282->master: status.py: Restore brackets to time in job display area) #308 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/308 | 09:14 |
| *** jonathanmaw has joined #buildstream | 09:17 | |
| jonathanmaw | Hi, I'm looking into source mirroring for buildstream, and was planning to compare it to buildstream's remote artifact cache, but I'm having trouble finding where the code for that is | 09:18 |
| tristan | jonathanmaw, I would say, don't jump the gun on source mirroring; there are a bunch of aspects to consider | 09:19 |
| tristan | On the one hand, if we had a single list of mirrors configuration, and a server side helper which facilitates mirroring using already built-in features (like it's mostly a variant of `bst fetch`) | 09:20 |
| *** valentind has joined #buildstream | 09:21 | |
| tristan | Then we could have a simple configuration story, and pretty easy to setup mirroring | 09:21 |
| tristan | On the other hand, we could have a more complicated config story; allowing say, alternative urls for each source alias | 09:21 |
| tristan | And then we could externalize the actual mirroring process entirely; plausibly supporting more exotic setups | 09:22 |
| tristan | Or... <insert your creative and better idea here>. | 09:23 |
| tristan | there is always that third alternative :D | 09:23 |
| tristan | Another thought is that the second approach does not really prevent the first, more hands-on / automated approach | 09:24 |
| tristan | So it could be a matter of getting some functionality now, while leaving the door open for more functionality later | 09:24 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 09:26 |
| *** tiago has joined #buildstream | 09:48 | |
| Nexus | is tristan still around? | 09:52 |
| tristan | Yep | 09:53 |
| Nexus | tristan: please could you have a look at https://gitlab.com/BuildStream/buildstream/merge_requests/310 for me? :) | 09:53 |
| tristan | Nexus, you mean https://gitlab.com/BuildStream/buildstream/merge_requests/310#note_62214798 ? | 09:54 |
| Nexus | oh yeah :D | 09:54 |
| Nexus | ty | 09:54 |
| * Nexus wonders why he didn't get an email | 09:55 | |
| *** dominic has joined #buildstream | 10:06 | |
| gitlab-br-bot | buildstream: merge request (jmac/remove-sequence-id->master: Remove sequence ID.) #309 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/309 | 10:07 |
| gitlab-br-bot | buildstream: merge request (jmac/remove-sequence-id->master: Remove sequence ID.) #309 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/309 | 10:09 |
| Nexus | So how do i define a new %{foo} variable for projectconfig.yaml to use? | 10:20 |
| *** valentind has quit IRC | 10:20 | |
| tristan | Nexus, I think one part, is that you would define `element` as an empty string, beside `max-jobs`, with a similar note about how that is a magically automated variable | 10:23 |
| tristan | Nexus, then you would define %{build-root} as `/buildstream/%{element}` | 10:24 |
| tristan | Nexus, the final part, would happen in Element initialization | 10:24 |
| juergbi | we already have project-name somewhat similar | 10:24 |
| juergbi | maybe call it element-name for consistency? | 10:25 |
| tristan | in a similar way that you had the original patch, only you would be assigning the element name to the variable | 10:25 |
| tristan | juergbi, +1 | 10:25 |
| tristan | Also | 10:25 |
| tristan | build-root: '/buildstream/%{project-name}/%{element-name}' | 10:25 |
| tristan | Might be a good idea | 10:25 |
| tristan | Would be a good idea I think | 10:25 |
| juergbi | sounds sensible | 10:26 |
| juergbi | follows the approach in the artifact cache | 10:26 |
| juergbi | we just can't have a project called 'install'.... | 10:26 |
| Nexus | so do project-name in the same way as element? | 10:27 |
| tristan | As a nitpick, `project-name` is code in _project.py, it could also use an empty declaration in projectconfig.yaml for documentation purposes, at the same place. | 10:27 |
| tristan | Nexus, project-name is already assigned, undocumented | 10:27 |
| * tlater wonders if source-bundle with junctions may potentially break lacking %{project-name} in the build path. | 10:28 | |
| Nexus | so define element in element __init__ and project-name exists but should be added to projectconfig? | 10:28 |
| tristan | juergbi, oops, good point | 10:28 |
| tristan | juergbi, OR, we set %{install-root} = `/buildstream-install` | 10:28 |
| tristan | I think that is nicer, because when you want to be in a shell and have your build trees around; it's just sexier without the extra `/build/` path component | 10:29 |
| Nexus | want me to change that too? | 10:30 |
| tristan | Nexus, Yep :) | 10:30 |
| tristan | and yes to your last, sounds about right | 10:30 |
| Nexus | kk :) | 10:30 |
| tristan | Do we need a specific test case for this ? | 10:30 |
| tristan | seems like, if current tests pass, it works | 10:31 |
| tristan | Nexus, there is always a chance that there is stray hard code referring to `/buildstream/build` and `/buildstream/install`, that may have to be fixed consequently; I suspect in the bst-external repo that may happen | 10:33 |
| Nexus | i'll have a look | 10:34 |
| Nexus | tristan: is ` self._variables['project-name'] = self.name` the line you were refering to that sets the projectconfig value? | 10:44 |
| tristan | hmmm, still no backpointer from Source -> Element ? | 10:44 |
| tristan | Nexus, it is, it's a line which exists in _project.py | 10:45 |
| Nexus | ok so self._variables['element'] = self.normal_name would work in the element init? | 10:45 |
| tristan | errrm | 10:46 |
| tristan | self.name I think ? | 10:46 |
| tristan | What do we still use normal_name for...; oh yeah, artifact cache strings ? | 10:46 |
| Nexus | i THINK normal name replaces spaces with '-' but i'm not certain | 10:46 |
| tristan | it does | 10:46 |
| Nexus | which is what would be needed for a path | 10:46 |
| tristan | no it does not | 10:46 |
| tristan | it only replaces the `.` | 10:47 |
| tristan | artifact cache does a more extensive thing | 10:47 |
| tristan | And normal_name, probably needs to go | 10:47 |
| Nexus | right ok, so use self.name | 10:47 |
| tristan | Yeah, self.name is the element directory relative bst filename | 10:47 |
| tristan | So, it is already a valid filename | 10:48 |
| tristan | and it also happens to be what we mostly use to display to users | 10:48 |
| Nexus | cool | 10:48 |
| tristan | ah right, normal_name splits the path separators, so core/totem.bst becomes core-totem.bst | 10:48 |
| tristan | in *any* case, stick with element.name please :) | 10:49 |
| * tristan thinks we use normal_name for build directories in ~/.cache/buildstream/build, but even that is unnecessary | 10:50 | |
| tlater | Is the utils._process_list (and utils.{link,copy}_files) helper guaranteed to work with files in any order? https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/utils.py#L614 | 10:51 |
| * tlater suspects directories need to be listed before files contained in them | 10:51 | |
| tlater | Bit of a shame, I'd love to use set operations for some stuff here :| | 10:52 |
| tristan | tlater, required, see comment in beginning of same function | 10:56 |
| tristan | tlater, I think we have a corresponding test case too which exposes the problem if you dont have that sort | 10:56 |
| tlater | tristan: My question is if that sorted(filelist) call there is enough to do the sorting for me should I give it an unsorted list | 10:57 |
| tristan | It should be | 10:58 |
| tristan | heh | 10:58 |
| tristan | tlater, that is a mind-numbing topic, cant answer off the top of my head to be honest | 10:58 |
| * tlater hoped someone could ;) | 10:59 | |
| tristan | I guess a better answer is, if it breaks; we need a test case + fix | 10:59 |
| Nexus | ah, normal name replaces the '/' with - and removes the .bst | 11:00 |
| tristan | tlater, which means "trust it" | 11:00 |
| * tlater will trust it | 11:00 | |
| tlater | :) | 11:00 |
| tlater | Whoo, cheap set operations! | 11:00 |
| tristan | Nexus, right | 11:00 |
| tristan | Nexus, probably *also* used in artifact paths; and cached on Element to avoid repeating the thing | 11:01 |
| tristan | Nexus, since you have me thinking of this... I've spotted another bug | 11:03 |
| tristan | If a user sets `project-name`, `max-jobs` or now `element-name` in their project.conf or element.bst files; we should probably bail out with LoadError | 11:04 |
| tristan | Nexus, I'll file it separately | 11:05 |
| Nexus | it seems like _project self.name is not declared early enough to work in this? it's coming up as blank | 11:05 |
| tristan | Oh ? | 11:05 |
| tristan | That smells like a regression | 11:05 |
| tristan | We chopped up project load at some point I think | 11:06 |
| Nexus | running `print("project-name: ".format(self.name))` the line before `self._variables['project-name'] = self.name` in _project.py returns project-name: | 11:06 |
| tristan | Nexus, that seems impossible, it's correct | 11:06 |
| tristan | Weird | 11:07 |
| tristan | Nexus, look at the _load() function though, name is the first thing that is every loaded | 11:07 |
| tristan | waaaay before that statement | 11:07 |
| tristan | Ah | 11:08 |
| tristan | Nexus, your format string is to blame ! | 11:08 |
| Nexus | ?? | 11:08 |
| tristan | try "project-name: {}" | 11:08 |
| Nexus | did i do a dumb? | 11:08 |
| Nexus | fk. | 11:08 |
| Nexus | xD | 11:08 |
| Nexus | project-name: gnome | 11:08 |
| Nexus | neat | 11:09 |
| Nexus | SO | 11:09 |
| Nexus | that works, but build-root: "/buildstream/%{project-name}/%{element}" seems to run with %{element} having no value | 11:09 |
| Nexus | hmmmm | 11:09 |
| tristan | Right, that *all* happens before Variables() is ever instantiated | 11:09 |
| tristan | so all of that manually setting of stuff, happens in yaml loaded nodes | 11:10 |
| tristan | Once you instantiate the Variables() instance, all bets are off; build-root wont resolve again | 11:11 |
| Nexus | i'm doing it way before then | 11:11 |
| tristan | I dont see how | 11:11 |
| Nexus | self.__variables = Variables(variables) iscalled on ln 183 for me, i'm running my code on ln 154 | 11:12 |
| Nexus | but my code may be wrong, as i was trying to hack togather something similar to _project | 11:12 |
| tristan | Wouldnt it be done after __extract_variables() ? | 11:12 |
| Nexus | it says i can't modify that value | 11:13 |
| tristan | It says ? | 11:13 |
| Nexus | 1 sec | 11:13 |
| Nexus | Variables' object does not support item assignment | 11:14 |
| Nexus | but i did it too late | 11:14 |
| Nexus | doing it after __extract_variables works | 11:14 |
| tristan | Right | 11:14 |
| Nexus | that gives me /buildstream/gnome/base-ninja | 11:14 |
| Nexus | as my path | 11:14 |
| tristan | Not /buildstream/gnome/base/ninja.bst ? | 11:15 |
| tristan | What do we prefer then ? | 11:15 |
| Nexus | no, atm i'm using normal_name | 11:15 |
| tristan | juergbi, thoughts ? | 11:15 |
| tristan | I think... use name | 11:15 |
| Nexus | that is a lot of subdirs though | 11:15 |
| tristan | Because we always show the user the name | 11:15 |
| juergbi | having the directory ending with .bst is a bit odd | 11:15 |
| juergbi | but it doesn't really matter to me | 11:16 |
| juergbi | but then we should use it everywhere | 11:16 |
| tristan | I agree, and would want to push for that | 11:16 |
| juergbi | also for build directories | 11:16 |
| Nexus | /buildstream/gnome/base/ninja.bst <-- output of name | 11:16 |
| tristan | I would want to kill normal_name entirely frankly | 11:16 |
| Nexus | havign a dir end with .bst seems a bit confusing to me | 11:17 |
| tristan | it's a source of confusion internally, and externally; I dont see why to have it either; give the user always one name | 11:17 |
| Nexus | but i can see why you don't want normal_name | 11:17 |
| juergbi | we do currently use normal_name in the artifact cache but i don't think we really need to | 11:17 |
| tristan | Yeah, it would be an artifact version bump there too | 11:18 |
| Nexus | so, decision? | 11:27 |
| tristan | Nexus, element.name | 11:28 |
| Nexus | so /buildstream/foo/bar/baz | 11:28 |
| Nexus | bar.baz* | 11:28 |
| Nexus | are you making a seperate issue for removing instances of "normal_name"? | 11:29 |
| gitlab-br-bot | buildstream: issue #287 ("Special / Magic variables are unprotected") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/287 | 11:29 |
| tristan | Yes | 11:32 |
| gitlab-br-bot | buildstream: issue #288 ("Kill Element.normal_name variable") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/288 | 11:33 |
| Nexus | lol | 11:34 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 11:38 |
| gitlab-br-bot | buildstream: issue #260 ("Regression: Not possible to import/export artifacts using different build architecture.") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/260 | 11:40 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 11:46 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 11:52 |
| jennis | juergbi, tlater re what we discussed about the pylint configuration file, the earlier commits on that branch should (hopefully) be what you wanted | 11:53 |
| jennis | ^^ | 11:53 |
| juergbi | jennis: fedora-6? or is that a typo? | 11:55 |
| tlater | juergbi: I used fedora-6 afaik | 11:56 |
| tlater | Image ID 422dc563ca32, to be exact x) | 11:57 |
| juergbi | it's just an odd version number | 11:57 |
| juergbi | i assume it has nothing to do with Fedora 6 | 11:57 |
| juergbi | i.e., i have no idea how to get from fedora-6 to the version | 11:58 |
| Nexus | omg all of the /buildstream/install hard codes D: | 11:59 |
| tristan | heh | 11:59 |
| tlater | juergbi: Huh, docker has odd versioning here, it seems. Looking at it more closely it's 27 | 12:00 |
| tlater | jennis: Probably want to amend that commit then, my bad | 12:00 |
| Nexus | tristan: in ./buildstream/plugins/elements/script.yaml how should i deal with the buildroot def? | 12:00 |
| jennis | tlater, just reword yeah? | 12:01 |
| tlater | Yep | 12:01 |
| tristan | Nexus, remove the assignments in there, but make it a documented comment in same file | 12:01 |
| tristan | Nexus, in tests, looks like there are not that many | 12:01 |
| tlater | Also, jennis, there are some changes here that I'd probably not make: https://gitlab.com/BuildStream/buildstream/merge_requests/283/diffs?commit_id=10aed0531244d04591ae8e8db6c1e038e48c5705 | 12:01 |
| tristan | Ummm | 12:01 |
| Nexus | tristan: i've changed them all, there were ~12 i think | 12:02 |
| tristan | Nexus, might be a bit more complicated for script element... | 12:02 |
| tristan | We may need to change that | 12:02 |
| tlater | jennis: I feel that's probably down to the confusing way in which we patched this... Mind if I just amend that commit for you? | 12:02 |
| jennis | go for it | 12:03 |
| tristan | Nexus, ok - I got it | 12:04 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 12:04 |
| * tlater wonders if there's a nice way to make a temporary commit so I can switch branches *without* having to reset said commit later | 12:04 | |
| juergbi | tlater: stash | 12:04 |
| tristan | Nexus, remove the mention of %{build-root} in that .yaml file altogether | 12:05 |
| * tlater will finally read up on stash next time he comes across this problem | 12:05 | |
| tristan | Nexus, its documented for no reason, absolutely pointless and unused | 12:05 |
| tlater | ta juergbi ;) | 12:05 |
| Nexus | fair enough | 12:05 |
| juergbi | tlater: for the simplest case of quick branch switching it's just: git stash && git checkout foo && do something && git checkout - && git stash pop | 12:05 |
| juergbi | (assuming you don't stash while on the other checkout) | 12:06 |
| tristan | Nexus, for install-root, comment it as I said, it is basically API, the element declaration author is allowed to set it and it will be used | 12:06 |
| tristan | Nexus, and of course, update the commented value to reflect the new default; I think it's worthwhile to duplicate that value in that comment anyway | 12:07 |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 12:10 |
| Nexus | Can someone please have a look at the fails i'm getting in those tests? I'm not sure what they mean, it seems to have something to do with cache keys? | 12:10 |
| jmac | Looking | 12:11 |
| Nexus | ty | 12:11 |
| jmac | That test is still running, I don't know how to get back to a previous result | 12:12 |
| jmac | Ah, found it | 12:12 |
| Nexus | wait until the test is done, i fixed a lot of errors in the last one | 12:12 |
| jmac | Is it just saying you changed the cache key calculation, so you need to regenerate it? | 12:17 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 12:18 |
| tristan | Nexus, yep that's expected | 12:18 |
| tristan | Nexus, when changing %{build-root} and %{install-root}, it will effect cache keys of elements which format instructions based on those values | 12:19 |
| juergbi | tristan: btw, as you looked at #10. do you think we should depend on host dpkg or directly access the ar archive (pyar)? | 12:19 |
| tristan | good question | 12:20 |
| tristan | juergbi, how difficult of a dependency is pyar is a factor; pure python ? | 12:20 |
| juergbi | actually, i meant arpy | 12:21 |
| juergbi | yes, i think it's pure python, it's on pypi | 12:21 |
| juergbi | https://pypi.python.org/pypi/arpy | 12:21 |
| tristan | juergbi, another factor is; running host commands is pretty robust as far as child process control goes; is arpy going to be trouble in suspend/resume ? | 12:21 |
| juergbi | i don't expect it to be more problematic than tarfile, which we also use | 12:22 |
| juergbi | but i have no experience with it | 12:22 |
| tristan | And another consideration is; is there *any* chance that host dpkg is going to extract anything based on host site assumptions ? | 12:22 |
| juergbi | no idea | 12:22 |
| tristan | maybe munge package metadata ? | 12:22 |
| tristan | yeah; I have no idea of these things either | 12:22 |
| tlater | jennis: Really appreciate the branch, I'm looking forward to "M-x flycheck-list-errors" being useful :) | 12:28 |
| tlater | There's one final comment from me, would you mind taking a look again after, juergbi? | 12:28 |
| juergbi | i will | 12:29 |
| tlater | This MR, for reference: https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 12:29 |
| tristan | with all the activity today, I've made progress on cleaning up my project.refs branch... much less messy, still lacks some needed optionality; namely explicit track on junctioned elements | 12:29 |
| tristan | And of course, a crap-ton of test cases | 12:30 |
| tristan | if I'm lucky, it's all done over this weekend | 12:30 |
| * tlater wonders how many bytes of test cases fit in a crap-ton | 12:31 | |
| *** tristan has quit IRC | 12:36 | |
| *** tristan has joined #buildstream | 12:39 | |
| tristan | Nexus, https://gitlab.com/BuildStream/buildstream/-/jobs/56407299 seems to be hung, you might try running the integration tests locally | 12:50 |
| tristan | oh wait, it didnt hang for linux ? | 12:50 |
| tristan | weird, that means... probably unrelated, but bad spurious error ? | 12:50 |
| tlater | tristan: I've seen this on occasion, I think it's a gitlab bug | 12:51 |
| tlater | It happens when docker fails to spin up on the host for some reason | 12:51 |
| tlater | Oh, it unhanged itself :) | 12:52 |
| paulsherwood | is there a hello-world bst example anywhere? | 12:55 |
| paulsherwood | ie minimal set of bst definitions to start from creating a totally new thing? | 12:55 |
| tlater | Nexus^^^? | 12:57 |
| paulsherwood | i can't find a single *example* bst file in the docs... how is a new user supposed to get started? | 13:01 |
| paulsherwood | all the quotes seem to be parts of things, not a full example. maybe it's me misunderstanding | 13:03 |
| tlater | paulsherwood: There is this repo, which is still WIP, but we would like to have some example projects there soonish: https://gitlab.com/BuildStream/buildstream-examples | 13:04 |
| tlater | Atm there is something like this in the docs somewhere | 13:04 |
| tlater | But I didn't pay close enough attention to know how to find it :( | 13:04 |
| tlater | Perhaps some restructuring would be nice | 13:04 |
| paulsherwood | /src/netsurf-flatpak> bst build netsurf-flatpak.bst | 13:11 |
| paulsherwood | [--:--:--] START Loading pipeline | 13:11 |
| paulsherwood | [00:00:00] FAILURE Loading pipeline | 13:11 |
| paulsherwood | Error loading pipeline: netsurf.bst [line 4 column 12]: Unexpected key: junction | 13:11 |
| * paulsherwood creates an empty repo... creates an empty bst file ... tries bst build... | 13:22 | |
| paulsherwood | Error loading project: Could not find file at /src/project.conf | 13:22 |
| * paulsherwood touches project.conf | 13:22 | |
| paulsherwood | Error loading project: /usr/local/lib/python3.6/site-packages/buildstream/data/projectconfig.yaml [line 6 column 0]: Dictionary did not contain expected key 'name' | 13:23 |
| * paulsherwood finds that bst build foo fails to notice foo.bst | 13:25 | |
| tristan | paulsherwood, I just got back from obtaining food and going to eat; first errors is due to you not having an up-to-date buildstream, and whatever project netsurf-flatpak.bst comes from not requiring the minimal format version where junctions exist | 13:29 |
| tristan | The latter part would have given you a more comprehensive error | 13:29 |
| tristan | A project.conf cannot not have a name, that is not allowed | 13:30 |
| tristan | the error message being wrong however, really sucks | 13:30 |
| paulsherwood | tristan: thanks. how do i update my buildstream? | 13:31 |
| tristan | git pull --rebase should be enough | 13:31 |
| paulsherwood | (am using bst-here) | 13:31 |
| tristan | I've never used that... hrmmm, tlater ? | 13:31 |
| tristan | ssssam[m] ? | 13:31 |
| paulsherwood | next up: i have a bst file that has literally only "kind: manual" in it... | 13:32 |
| tristan | that should do absolutely nothing I suppose, if not raise an error | 13:32 |
| paulsherwood | tristan: guess how many lines of output it gives me? :) | 13:32 |
| *** ChanServ sets mode: +o ironfoot | 13:33 | |
| paulsherwood | https://paste.baserock.org/xobanacepo | 13:33 |
| paulsherwood | is bst making a whole load of linux assumptions? | 13:33 |
| tristan | looking at bst-here, it should pull the latest build of the fedora based docker images | 13:34 |
| paulsherwood | every time bst-here is run? | 13:34 |
| tlater | Ah, sorry, was away for a sec | 13:35 |
| tristan | I guess, if I had any clue whatsoever about anything about docker, I might be able to tell you | 13:35 |
| tristan | https://gitlab.com/BuildStream/buildstream-docker-images/pipelines looks like it has not produced a fedora image in a while | 13:35 |
| tristan | So perhaps these builds are not automated ? | 13:35 |
| tlater | paulsherwood: bst-here is partially designed to be used on macs | 13:36 |
| tlater | I'm not aware of any linux assumptions | 13:36 |
| paulsherwood | tlater: i know. that's why i'm using it. now how do i update its bst ? | 13:36 |
| * skullman ran bst-here in his buildstream checkout and ran python3 setup.py install to get a recent version | 13:36 | |
| tristan | paulsherwood, ah, your manual element is default inheriting the strip-commands, which seems reasonable | 13:36 |
| tlater | paulsherwood: I think you need to manually update the docker image | 13:36 |
| * tlater figures out the command | 13:36 | |
| tristan | but; we could do better to report an error when someone tries to run something in a runtime with nothing in it | 13:37 |
| tlater | paulsherwood: `sudo docker pull buildstream/buildstream-fedora` should do it | 13:37 |
| paulsherwood | skullman: ack, i'll try that | 13:37 |
| * tlater wonders if that script should have an 'update' command or something | 13:37 | |
| gitlab-br-bot | buildstream: issue #289 ("Need better errors when running something on nothing") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/289 | 13:40 |
| tlater | tristan: Should we perhaps make bst-here check for and update to new docker images, as well? | 13:40 |
| tristan | tlater, it should have something that is self sustainable, or buildstream-docker-images should have a maintainer, or something :) | 13:40 |
| paulsherwood | needs better *behaviour* when run on nothing too... shouldn't need a project.conf | 13:40 |
| tristan | that is a rando script hanging out in contrib/ to me | 13:41 |
| gitlab-br-bot | buildstream: issue #290 ("retry doesn't always work when a build error is found") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/290 | 13:41 |
| tlater | The problem in this case isn't that the docker image is out-of-date afaik | 13:41 |
| tlater | It's just that `docker run` doesn't actually run the latest image | 13:41 |
| tristan | paulsherwood, you absolutely need a project.conf with a name, that wont change; a better error message if a project.conf is missing maybe | 13:41 |
| tlater | So you need to manually ensure your docker has the latest image | 13:42 |
| tristan | project.conf is the root of what defines your project, basically | 13:42 |
| paulsherwood | tristan: why cant $name be whatever the target is that i specify? | 13:42 |
| tristan | maaaaybe a default name but, that seems rather weird | 13:42 |
| jmac | The target name you specify is an element name, not the project | 13:42 |
| tristan | the target you are building, is not the project | 13:42 |
| paulsherwood | (if no project.conf exists?) | 13:42 |
| * paulsherwood is a n00b on bst, doesn't yet understand what an element is | 13:43 | |
| tristan | element = target; bst is a pipeline of elements; each one can be a target | 13:43 |
| paulsherwood | if the 'project' is in effect everything in the directory i'm in, then default to $dirname ? | 13:44 |
| tristan | artifacts and everything need to be namespaced | 13:44 |
| tristan | one pipeline can always have multiple projects, projects depend on eachother via junction elements | 13:44 |
| jjardon[m] | paulsherwood: pip3 uninstall buildstream; pip3 install --user buildstream_repo/ | 13:44 |
| tristan | jjardon[m], bst-here script in contrib/ | 13:44 |
| tlater | jjardon[m]: That won't work inside the docker container ;) | 13:44 |
| jmac | I'd rather bst just show a very clear error message explaining how to create a minimal project.conf in that case | 13:45 |
| jjardon[m] | tlater I don't use docker containers | 13:45 |
| * Nexus was afk, has anyone pointed paulsherwood to my beginner docs? | 13:45 | |
| jjardon[m] | tristan I know nothing about that script :) | 13:45 |
| tristan | jjardon[m], the person you are recommending to use pip, is | 13:45 |
| tristan | jjardon[m], I know very little about it also, only that it's in use by people who want it to exist in contrib/ | 13:46 |
| jjardon[m] | tristan I simply follow the docs to install and update buildstream; it works OK for me | 13:47 |
| tristan | (who are more numerous than paulsherwood, I know it's regularly used) | 13:47 |
| dominic | Nexus, I would like to see those if you have a link? | 13:47 |
| tristan | jjardon[m], this is not a meaningful conversation :) | 13:47 |
| tristan | jjardon[m], are you asking for help to upgrade your bst ? | 13:47 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: WIP: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 13:47 |
| *** ernestask has joined #buildstream | 13:47 | |
| jjardon[m] | http://buildstream.gitlab.io/buildstream/install.html#installing | 13:48 |
| Nexus | dominic: https://gitlab.com/BuildStream/buildstream/issues/169 | 13:48 |
| jjardon[m] | Tristan not me, paulsherwood have asked | 13:48 |
| dominic | Nexus, thanks :) | 13:48 |
| tristan | jjardon[m], and we both told you that he is using bst-here, not pip, so this thread can easily just... not happen :) | 13:49 |
| Nexus | dominic: the links in there are all related to branches in that repo too | 13:49 |
| Nexus | named things like "install" | 13:49 |
| jjardon[m] | tristan yep sorry I missed that; maybe a good moment to document bst-here in the installation guide? | 13:51 |
| gitlab-br-bot | buildstream: merge request (sam/compose-symlinks-issue->master: Avoid compose element dropping files that are staged inside directory symlinks) #295 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/295 | 13:53 |
| gitlab-br-bot | buildstream: issue #291 ("Updating buildstream is non-trivial with bst-here") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/291 | 13:56 |
| *** jonathanmaw has quit IRC | 13:58 | |
| tristan | jjardon[m], <I'm really gonna eat my cooling off food this time/>... I suppose it could live in main bst docs; although the script itself is meant to be stand-alone and self-documenting; it's rather a "external thing we keep in contrib/" right now | 14:05 |
| tristan | jjardon[m], I wouldnt oppose a patch which documents it, though | 14:06 |
| tristan | (in the html) | 14:06 |
| tristan | oh look at that, it *is* in the docs, but a bit too obscure | 14:07 |
| tristan | http://buildstream.gitlab.io/buildstream/docker.html#docker | 14:08 |
| tristan | linked from first section in http://buildstream.gitlab.io/buildstream/install.html#installing | 14:08 |
| jjardon[m] | oh nice, sorry for the noise then | 14:22 |
| tristan | no worry, it needs better documentation | 14:22 |
| tristan | and it needs to be self sustainable in general | 14:22 |
| paulsherwood | Nexus: no, where are your beginner docs? | 14:22 |
| paulsherwood | jjardon[m]: i'm using the docker route, tlater's magic worked for me | 14:23 |
| dominic | paulsherwood, <Nexus> dominic: https://gitlab.com/BuildStream/buildstream/issues/169 | 14:23 |
| Nexus | ^ | 14:24 |
| jjardon[m] | paulsherwood: cool :) | 14:25 |
| paulsherwood | really? you kids today a actually think that documentation should be in the issue tracker? | 14:25 |
| * paulsherwood is just jealous about others being young, but really | 14:25 | |
| jennis | paulsherwood, there is also this https://wiki.gnome.org/Newcomers/BuildSystemComponent | 14:25 |
| jennis | Not sure if you've come across it | 14:25 |
| paulsherwood | cool. can there be a link to that, so that when n00b lands at bst via google, it's obvious where to start? | 14:26 |
| paulsherwood | actually, yes i've seen that... but it seems to be more about starting on gnome than starting with bst | 14:27 |
| gitlab-br-bot | buildstream: merge request (sam/compose-symlinks-issue->master: Avoid compose element dropping files that are staged inside directory symlinks) #295 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/295 | 14:27 |
| jennis | It was a good starting point to actually get `bst build foo` working, as you mentioned earlier | 14:27 |
| paulsherwood | jennis: true, however... i'm expressly acting like a busy user who doesn't have much time (because actually i am) and i just want a painless 'get started' experience... i was hoping to be up-and-running in way less than an hour... | 14:29 |
| paulsherwood | as much as i admire bst from afar, i really don't have time to chase down docs via the issue tracker for example | 14:30 |
| jennis | haha no I totally understand | 14:30 |
| paulsherwood | so, back to this... who is actually documenting that 'getting started' experience, please? | 14:32 |
| gitlab-br-bot | buildstream: issue #292 ("bst doesn't use an open workspace for a junction") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/292 | 14:32 |
| tlater | paulsherwood: The docs you just looked at are exactly that, actually. We use the gnome base for historical reasons, but it's not actually related to gnome. | 14:33 |
| paulsherwood | they're not that. they are *really* not that | 14:34 |
| dominic | yeah, I had trouble when just using those | 14:34 |
| jennis | +1 | 14:34 |
| *** mcatanzaro has joined #buildstream | 14:35 | |
| jjardon[m] | tlater: getting started should really be at https://buildstream.gitlab.io/buildstream/, not in a GNOME; thats something me and tristan wrote as a replacement for the previous jhbuild guide we had | 14:35 |
| paulsherwood | i am a n00b. i don't know what(tf) bst is. tell me a) what it's for in a couple of sentencess. b) how to install it (via a link if it's complex) c) how to do 'hello-world' within 10 minutes, and without any words i don't understand d) where to dig deeper | 14:35 |
| * tlater thought that was what the docs Nexus linked to contained, but will concede | 14:36 | |
| paulsherwood | bonuse points if you make the doc attractive and fun | 14:36 |
| sstriker | #292, workspacing a junction. Hadn't thought of that one yet. | 14:38 |
| gitlab-br-bot | buildstream: issue #293 ("Write "getting started" guide") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/293 | 14:39 |
| * paulsherwood wonders what is a 'junction' is, and finds that there's no glossary for bst? | 14:40 | |
| jennis | I think the information is there, but atm I think there is "somewhere" | 14:40 |
| * tlater agrees with jennis - we have a lot of branches with almost-done documentation lying around | 14:40 | |
| paulsherwood | :/ | 14:40 |
| jjardon[m] | paulsherwood: hope you dont mind I stole your words to open that issue | 14:41 |
| paulsherwood | jjardon[m]: no problem :-) | 14:42 |
| sstriker | I thought there was more here https://buildstream.gitlab.io/buildstream/ at first. Seems to have shed some content? Hmm, where did the useful TOC go? I can find what I need via google but not direct: https://buildstream.gitlab.io/buildstream/elements/junction.html | 14:45 |
| juergbi | 'Authoring Projects' is where the information is for people who write/modify elements (.bst files) | 14:57 |
| juergbi | 'Using BuildStream' => 'Invoking BuildStream' is for the CLI documentation | 14:58 |
| juergbi | maybe we should flatten 'Using BuildStream' as that just contains two links | 14:59 |
| juergbi | and maybe insert the word API in the link/title of 'Core documentation and reference' | 14:59 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 15:07 |
| gitlab-br-bot | buildstream: merge request (sam/compose-symlinks-issue->master: Avoid compose element dropping files that are staged inside directory symlinks) #295 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/295 | 15:09 |
| gitlab-br-bot | buildstream: issue #282 ("Status bar regression after enhancing log configurability") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/282 | 15:23 |
| *** Prince781 has joined #buildstream | 15:24 | |
| gitlab-br-bot | buildstream: merge request (bst-here-update->master: bst-here: Add '-u' flag to upgrade buildstream (Issue #291)) #311 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/311 | 15:27 |
| gitlab-br-bot | buildstream: issue #258 ("Configurable log line formatting") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/258 | 15:29 |
| jennis | Has anyone already achieved a work-around to having "../<to_plugin>" in the project.conf | 15:40 |
| jennis | ? | 15:40 |
| paulsherwood | ok, so in the presence of a project.conf file, what's the simplest single bst file that will actually pass for bst build? | 15:44 |
| paulsherwood | `kind: manual` hits the strip commands fail i mentioned earlier | 15:45 |
| * paulsherwood is considering using bst to model a pipeline of mapped documents (eg some yaml structures with no real code underneath them) | 15:45 | |
| * paulsherwood feels like he may have scared the bst folks into silence | 16:03 | |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 16:03 |
| jennis | juergbi, tlater has reviewed !283 and resolved the discussions. Would you be able to add this to your list? :) | 16:04 |
| juergbi | yes | 16:04 |
| tlater | \o/ | 16:04 |
| * tlater is *so* looking forward to clean emacs fringes | 16:05 | |
| juergbi | paulsherwood: i'd recommend you to disable strip-commands in project.conf in that case | 16:05 |
| juergbi | not quite sure i understand your pipeline, though. if you want to process documents, the corresponding processing tools need to be either built or imported into buildstream | 16:06 |
| ssssam[m] | paulsherwood: you won't ever really have a project with a single .bst file | 16:06 |
| juergbi | i assumed that would just be that start but maybe i misunderstood | 16:07 |
| ssssam[m] | probably the most minimal would be; a base.bst file that is an 'import' element that pulls in binaries of the tools you need; then a 'do-stuff.bst' that uses those tools to do something | 16:07 |
| juergbi | you can have a single element that imports a document and doesn't do anything | 16:07 |
| juergbi | it's not particularly useful, of course ;) | 16:08 |
| paulsherwood | can the strip-commands be made to succeed on empty? | 16:08 |
| ssssam[m] | i'm not sure i'd call that a "build pipeline" :-) | 16:09 |
| * paulsherwood is expecting to have multiple bst files... but is also trying to iron out this hello-world usecase on the way | 16:09 | |
| paulsherwood | ssssam[m]: agreed. but it could be a "hello world" demo of bst? | 16:09 |
| ssssam[m] | the issue there is that if you want stripping but it's not working, you might not notice | 16:10 |
| *** Prince781 has quit IRC | 16:10 | |
| ssssam[m] | oh, you mean succeed if there's nothing to strip? that could make sense | 16:10 |
| paulsherwood | yes, that's what i mean | 16:10 |
| ssssam[m] | Nexus: the docs at https://buildstream.gitlab.io/bst-external/ have a link to the 'quild' plugin, that seems wrong | 16:12 |
| paulsherwood | so https://paste.baserock.org/ebisubazif gives a successful pipeline | 16:12 |
| paulsherwood | how would i get hello-world to appear in its (admittedly lovely) output? | 16:12 |
| juergbi | hello-world is a file in the same repo? | 16:13 |
| paulsherwood | not yet it isn't... but if that's the best way, let's saay yes :) | 16:14 |
| Nexus | ssssam[m]: did i add that? | 16:14 |
| juergbi | https://paste.baserock.org/nenujabeca | 16:14 |
| juergbi | paulsherwood: if it's not in the same repo, you have to use a different 'kind' of source. e.g., git | 16:15 |
| ssssam[m] | Nexus: I thought you were working on a quilt source plugin, did someone else do that? | 16:15 |
| Nexus | ssssam[m]: i worked on the quilt soruce plugin, but i never wrote docs for it that i can recall | 16:16 |
| paulsherwood | juergbi: nice try... but there's no sign of 'hello-world' in the output :-) | 16:16 |
| Nexus | apparently i did... | 16:16 |
| paulsherwood | i appreciate this is a silly example. ideally causing 'hello-world' to appear woudl demonstrate the power of (say) script running on the pipeline | 16:17 |
| ssssam[m] | all new features should be documented, so it would be kinda bad if you didn't ... | 16:18 |
| paulsherwood | eg like adding - configure-command: 'echo hello world' in a morph file | 16:18 |
| juergbi | paulsherwood: ah, i thought you wanted it in the built artifact, not in the log | 16:18 |
| juergbi | paulsherwood: to get echo working in the sandbox, you need to import an echo binary (or a shell with echo built-in) into the sandbox | 16:19 |
| paulsherwood | aha... there's a built artifact? the log doesn't tell me that!!!! :) | 16:19 |
| juergbi | there is an open bug about that | 16:19 |
| paulsherwood | :) | 16:19 |
| Nexus | ssssam[m]: hmm, let me have a look at what's going on | 16:19 |
| juergbi | https://gitlab.com/BuildStream/buildstream/issues/252 | 16:19 |
| juergbi | paulsherwood: you can get your artifact with: bst checkout yourelement.bst output-directory | 16:20 |
| paulsherwood | eek... still seems to me that bst folks don't understand, then. cache-keys should be reported at the start, not at the end | 16:20 |
| juergbi | they are, where possible | 16:20 |
| juergbi | it's not always possible, though | 16:20 |
| juergbi | see linked issue description | 16:21 |
| paulsherwood | https://paste.baserock.org/fevegodile - what's my artifact? | 16:21 |
| juergbi | cached 2beb60c1 foo.bst | 16:22 |
| juergbi | that's the (abbreviated) cache key but you don't actually need it to checkout | 16:22 |
| paulsherwood | which means precisely nothing to me as a drive-by user | 16:22 |
| paulsherwood | sorry, i'm being harsh today | 16:22 |
| juergbi | the planned summary for #252 and #247 should address this | 16:22 |
| paulsherwood | ack | 16:22 |
| juergbi | that's for the summary after build | 16:23 |
| juergbi | we're aware of the issue and it's already in our 'immediate priorities' milestone | 16:23 |
| paulsherwood | cool | 16:23 |
| *** Prince781 has joined #buildstream | 16:23 | |
| juergbi | btw: i just noticed that you already have a local '.' source | 16:24 |
| juergbi | that's normally not recommended as this means you import the whole repository including project.conf and the .bst file | 16:24 |
| juergbi | always use a path, can be a subdirectory or a single file | 16:24 |
| Nexus | ssssam[m]: that's been updated, just needs to be checked and merged | 16:25 |
| paulsherwood | juergbi: ack. i was just trying to get something to pass :) | 16:26 |
| juergbi | sure, understood | 16:26 |
| juergbi | btw: if you want to import a basic system so you can have echo and co., you could use ssssam[m]'s reasonably small alpine base image: https://paste.baserock.org/uhilaroxut | 16:27 |
| juergbi | with this alias in project.conf: https://paste.baserock.org/uwibowoyig | 16:28 |
| paulsherwood | juergbi: tvm | 16:28 |
| paulsherwood | i'm still trying to understand the previous example... | 16:28 |
| paulsherwood | so in theory my empty hello-world file would be in the artifact? | 16:28 |
| juergbi | yes, you can test with bst checkout | 16:28 |
| paulsherwood | but when i do bst checkout foo.bst bobbins -- my bobbins directory is empty | 16:28 |
| juergbi | hm, it isn't here | 16:29 |
| paulsherwood | odd... do i have to checkin hello-world? | 16:29 |
| juergbi | no, local doesn't know about git | 16:29 |
| paulsherwood | juergbi: ah, probably pebkac | 16:31 |
| * paulsherwood is *nearly* there, but .... https://paste.baserock.org/zotixopuhu | 16:45 | |
| juergbi | paulsherwood: project name with space that we don't support? | 16:46 |
| juergbi | we should really fix that, either error out or properly support it | 16:46 |
| paulsherwood | ack :) | 16:47 |
| jmac | I hit exactly the same problem | 16:47 |
| * paulsherwood has been failing to run software as its creators intend for some decades now :) | 16:47 | |
| juergbi | hehe | 16:49 |
| paulsherwood | https://paste.baserock.org/unayogukis | 16:54 |
| tlater | zo/ | 16:55 |
| tlater | Err | 16:55 |
| tlater | That wasn't supposed to be a 'z' | 16:55 |
| juergbi | :) | 16:55 |
| tlater | juergbi: Do you know what causes those ugly empty brackets btw? | 16:55 |
| * tlater believes this to not have been an issue before | 16:56 | |
| juergbi | might be a regression of the configurable log line | 16:56 |
| juergbi | brackets are part of the format and if the corresponding item is an empty string, we still see the brackets | 16:56 |
| tlater | Oh, right | 16:56 |
| juergbi | not sure how to best handle that | 16:57 |
| jmac | It did come in with the configurable log line, yes | 16:57 |
| jmac | I chose to handle them by considering them beautiful instead of ugly | 16:57 |
| * tlater isn't particularly happy with that solution, but not unhappy enough to immediately figure out how templating works here :| | 16:58 | |
| jmac | If it's really annoying then I will figure out a solution | 16:59 |
| tlater | Heh, I was considering changing the format in my local config :) | 16:59 |
| jmac | You can remove the brackets from the config, but they you won't get any brackets at all | 17:01 |
| tlater | I like the brackets if they're around something though | 17:02 |
| * tlater is hard to please | 17:02 | |
| jmac | I think if I just add a render-with-brackets function to the Widget base class we can get the old behaviour back | 17:02 |
| tlater | Hm, weren't we using a templating language for this, as we are for `bst show`? | 17:03 |
| tlater | If it's the same language I think it already has a feature to allow this sort of stuff | 17:03 |
| tlater | Just changing the default template might be better | 17:03 |
| tlater | Then again, I might misremember | 17:04 |
| jmac | ... you can't do that | 17:04 |
| tlater | Aww :( | 17:04 |
| jmac | The log line has a format string which you can change but there's nothing that formatting string that's clever enough to support optional brackets | 17:05 |
| jennis | juergbi, re the dir vs dir_, I can change this to directory as I'm reluctant to just disable the warning for this | 17:18 |
| juergbi | we do use a _ suffix in other places, so maybe we should leave that in the branch as is | 17:18 |
| juergbi | it just feels odd having to accommodate for the pretty much useless dir() built-in | 17:19 |
| juergbi | i wish we could disable the dir built-in instead | 17:19 |
| juergbi | or globally ignore the warning for 'dir' | 17:19 |
| juergbi | mostly a nitpick. i should probably not care that much about it | 17:19 |
| tlater | We can technically disable that, but I think it's generally bad - someone's going to spend 30 minutes debugging this only to remember dir() at some point | 17:20 |
| juergbi | you mean disable the whole warning class for builtins? i think the warning generally makes sense | 17:21 |
| juergbi | or could we disable it only for dir? | 17:21 |
| tlater | We can disable the warning specifically for dir, I *think* | 17:21 |
| juergbi | ok, so what would be the downside? | 17:21 |
| tlater | Someone might use dir() for its built-in reason | 17:21 |
| tlater | I.e., for a type check or something | 17:22 |
| tlater | Unlikely to cause issues, but a massive pain if it does | 17:22 |
| juergbi | hm, yes, if this is considered useful outside python interactive shell or similar, then we should probably not disable it | 17:23 |
| juergbi | "Because dir() is supplied primarily as a convenience for use at an interactive prompt, it tries to supply an interesting set of names more than it tries to supply a rigorously or consistently defined set of names" | 17:26 |
| juergbi | i say it's worse to actually use the built-in dir() in regular code than to use dir as variable name | 17:26 |
| juergbi | but maybe that's just me | 17:26 |
| juergbi | i want to invert the warning | 17:26 |
| * tlater thinks that is also possible | 17:28 | |
| juergbi | bad_builtin plugin | 17:28 |
| tlater | I think I agree here, actually, considering the doc | 17:28 |
| juergbi | ok, let's do that, then | 17:28 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: WIP: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 17:31 |
| juergbi | added comment on gitlab | 17:32 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: WIP: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 17:32 |
| *** noisecell has quit IRC | 17:43 | |
| Nexus | need to add dpkg to CI :p | 17:43 |
| juergbi | Nexus: you appear to have imported lots of binaries. accidentally? | 17:53 |
| Nexus | juergbi: it's the contents of the .deb i'm using in the tests | 17:54 |
| Nexus | if you have a smaller one i can use, i can swap it out, but the contents need to be there afaik | 17:54 |
| Nexus | also tristan, you were saying about the cache keys changing due to what i did with %{build-root} and %{install-root}. Can i fix that in the tests? | 17:58 |
| juergbi | maybe reference a small one from snapshot.debian.org? | 17:58 |
| juergbi | we shouldn't import binaries into git like that | 17:58 |
| juergbi | an alternative may be to create a .deb as preparatory step in the test itself | 18:00 |
| tristan | Nexus, yes; just do as the error message says and commit the result separately | 18:00 |
| Nexus | juergbi: how does http://ftp.debian.org/debian/pool/main/c/clod/lua-clod_1.0.2-3_all.deb look? | 18:02 |
| juergbi | size is good but i think we should use snapshot.debian.org to reduce risk of breaking over time | 18:03 |
| juergbi | older debs get removed from the main archive at some point | 18:03 |
| Nexus | can you order by tiny? | 18:04 |
| juergbi | http://snapshot.debian.org/archive/debian/20180308T040556Z/pool/main/c/clod/lua-clod_1.0.2-3_all.deb | 18:06 |
| Nexus | ty | 18:06 |
| *** dominic has quit IRC | 18:14 | |
| *** mcatanzaro has quit IRC | 18:41 | |
| *** valentind has joined #buildstream | 18:42 | |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: WIP: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 18:52 |
| Nexus | juergbi: replaced :) | 18:52 |
| *** xjuan has joined #buildstream | 18:58 | |
| *** tristan has quit IRC | 19:34 | |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: WIP: Add versioning to workspaces yaml configuration) #312 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/312 | 19:45 |
| *** Prince781 has quit IRC | 20:08 | |
| *** ernestask has quit IRC | 20:11 | |
| *** xjuan_ has joined #buildstream | 21:23 | |
| *** xjuan has quit IRC | 21:25 | |
| *** Prince781 has joined #buildstream | 21:49 | |
| *** noisecell has joined #buildstream | 22:21 | |
| *** noisecell has quit IRC | 22:24 | |
| *** valentind has quit IRC | 22:52 | |
| *** xjuan_ has quit IRC | 22:52 | |
| *** Prince781 has quit IRC | 23:00 | |
| *** Prince781 has joined #buildstream | 23:05 | |
| *** Prince781 has quit IRC | 23:26 | |
| *** Prince781 has joined #buildstream | 23:31 | |
| *** mcatanzaro has joined #buildstream | 23:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!