| *** Prince781 has joined #buildstream | 00:27 | |
| *** Prince781 has joined #buildstream | 00:29 | |
| *** mohan43u has quit IRC | 02:29 | |
| *** mohan43u has joined #buildstream | 02:47 | |
| mohan43u | hi, I'm new to buildstream. while building meta-gnome-core-shell.bst https://gist.github.com/mohan43u/6811f2d14134793a91014e8c400a0699 | 03:20 |
|---|---|---|
| mohan43u | then two or thee zombies hanging and nothing seems to be happening | 03:21 |
| mohan43u | any hints? | 03:21 |
| *** Prince781 has quit IRC | 04:36 | |
| juergbi | hi mohan43u, that was fixed yesterday in master | 05:30 |
| juergbi | buildstream master, that is | 05:30 |
| juergbi | https://gitlab.com/BuildStream/buildstream/merge_requests/333 and https://gitlab.com/BuildStream/buildstream/merge_requests/334 | 05:31 |
| *** tristan has quit IRC | 05:33 | |
| *** tristan has joined #buildstream | 06:02 | |
| mohan43u | juergbi: ok, I'll pull the changes. thanks | 06:09 |
| *** gitlab-br-bot has joined #buildstream | 08:42 | |
| gitlab-br-bot | buildstream: merge request (jjardon/contributing->master: Add HACKING document to official docs) #332 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/332 | 08:57 |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 09:00 |
| *** toscalix has joined #buildstream | 09:02 | |
| gitlab-br-bot | buildstream: issue #302 ("File permissions changing inside the sandbox") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/302 | 09:09 |
| mohan43u | hi, is /dev/fuse required for buildstream? | 09:24 |
| *** valentind has joined #buildstream | 09:26 | |
| juergbi | mohan43u: yes, FUSE is required for safe read-write access to the rootfs in the sandbox, which is used by integration commands | 09:33 |
| juergbi | it's not typically used during actual build commands such as configure and make but it's required by the overall build process | 09:34 |
| mohan43u | i'm struggling to make libvirt_lxc to insert /dev/fuse. is there any way to use buildstream inside libvirt container? | 09:35 |
| juergbi | hm, not sure, it works in docker containers. it doesn't work in (unprivileged) user namespaces. the latter will likely be fixed in linux 4.17 | 09:37 |
| tristan | mohan43u, like juergbi I'm not sure about that specific question; but depending on your needs, maybe the `bst-here` script can be helpful (http://buildstream.gitlab.io/buildstream/docker.html) ? | 09:37 |
| juergbi | fuse in user namespaces: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/log/?h=for-next | 09:38 |
| mohan43u | ok. I'll check bst-here, if it doesn't work. then I'll use my host system itself.. | 09:41 |
| juergbi | actual builds are all sandboxed, so the host system should not be at risk | 09:42 |
| juergbi | as buildstream doesn't require root privileges, you can also create a separate user if you want to ensure your regular home directory remains unaffected | 09:42 |
| mohan43u | seems docker run --device=/dev/fuse just expose /dev/fuse into the container.. this should be achievable in libvirt_lxc.. but I lack virsh/libvirt knowledge to do this stuff | 09:49 |
| *** jonathanmaw has joined #buildstream | 09:52 | |
| mohan43u | ok found, first need to define a host device in an xml (like this https://gist.github.com/bf2ae9a63822ad51aac29d1239eb62df) and then run 'virsh -c lxc:/// attach-device <containername> <fuse.xml> --config' then after container restart I got /dev/fuse in my container | 10:09 |
| mohan43u | thanks for help guys.. | 10:09 |
| juergbi | yw, thanks for posting the solution | 10:12 |
| tristan | juergbi, this is unfortunate about strip-commands :-S | 10:16 |
| tristan | On the one hand, it would be nice to have our defaults strictly POSIX compliant; except for plugin specific defaults which impose their own requirements (e.g. autotools imposes autotools tools themselves) | 10:18 |
| tristan | On the other hand, the more we do this, the more burden projects need to carry | 10:18 |
| *** aday has joined #buildstream | 10:18 | |
| tristan | juergbi, I wonder if we can have an "approach" for this sort of thing | 10:18 |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 10:19 |
| tristan | juergbi, Considering that "other hand", this is bigger than OS builders might think; e.g. if we're going to build Flatpaks and such; this is (burden * flatpaks), which would be a failure I think | 10:20 |
| juergbi | well, the flatpak plugin could presumably handle this in a way that is suitable for flatpaks | 10:20 |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 10:20 |
| juergbi | not sure about the general case | 10:20 |
| juergbi | although, the plugin could only do it later, not as part of the element | 10:21 |
| tristan | Can a plugin enforce project-wide defaults ? | 10:21 |
| *** dominic has joined #buildstream | 10:21 | |
| tristan | exactly, not as it stands | 10:21 |
| tristan | One approach *might* be to consider some sort of junction inheritance | 10:21 |
| tristan | looking at the very GNOME desktop with systemd specific (not even linux specific) stuff we have to support shells here: https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/project.conf#L113 ... was the first point I started to worry about this | 10:22 |
| tristan | Another approach I've been tossing around would be to offer some augmented "profiles" ? | 10:23 |
| tristan | such that a project could say "I'm a GNOME thing", and automatically pull in those shell configurations ? | 10:23 |
| juergbi | maybe somehow use `include` for this which we might reintroduce | 10:25 |
| juergbi | not sure how well this would fit here | 10:25 |
| tristan | you would have to get the thing to include from somewhere | 10:25 |
| juergbi | we'd have to support include via junction | 10:25 |
| tristan | or that | 10:25 |
| tristan | hmmm | 10:25 |
| tristan | With the inheritance approach; we could restrict this to some configurations; like environment, environment-nocache, variables, and the new sandbox | 10:27 |
| tristan | Eh, even that doesnt really work | 10:28 |
| tristan | because inheritance at that level does not propagate across dependencies | 10:28 |
| * tristan was thinking maybe, we introduce that in composition for elements which depend on a junction | 10:28 | |
| tristan | but that wouldnt make sense to propagate defaults through dependencies, not at all | 10:29 |
| tristan | include via junction sounds elegant, though; if doable - an upside to that is things get *extended* across projects | 10:30 |
| tristan | juergbi, so I would expect say, that freedesktop-sdk provides project-shell.inc, which is included in it's project.conf | 10:31 |
| tristan | juergbi, and then gnome-build-meta provides it's *own* project-shell.inc, which also includes the project-shell.inc from freedesktop-sdk | 10:31 |
| juergbi | yes, something along these lines | 10:34 |
| juergbi | and include would also be useful for .bst files, of course | 10:34 |
| * tristan should create an issue for this, without necessarily speccing out a solution but let's suggest this possibility | 10:42 | |
| tristan | juergbi, interestingly - I now notice that an include statement would need a parameter to control whether you include "above" or "below" | 10:47 |
| tristan | by default, you'd want to include "above", such that the literal dictionary is composited *on top* | 10:48 |
| tristan | but for the case of including these defaults from a junction, you would want to include it "below", and override that with the inline yaml | 10:48 |
| jennis | Is anyone else getting 503's? | 10:49 |
| jennis | https://buildstream.gitlab.io/buildstream/ | 10:49 |
| juergbi | i actually always prefer include below | 10:49 |
| tristan | juergbi, was just thinking that yeah; maybe it's best for all cases | 10:49 |
| tristan | why would you parameterize something that you know will be squashed by your include at all anyway ? | 10:50 |
| tristan | like that | 10:50 |
| tristan | good point | 10:50 |
| juergbi | and we should strongly recommend, or maybe even enforce, putting include at the top of the file (or dict, in case we support dict-level include) | 10:50 |
| tristan | hmm, this needs to be another (-) directive | 10:51 |
| tristan | not just the word "include", for consistency | 10:51 |
| tristan | I would think we would support dict-level inclusions | 10:51 |
| juergbi | yes, probably | 10:53 |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 11:01 |
| gitlab-br-bot | buildstream: merge request (jjardon/no_python2->master: .gitlab-ci.yml: No need to install python2 for docs job) #335 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/335 | 11:12 |
| gitlab-br-bot | buildstream: merge request (jjardon/no_python2->master: .gitlab-ci.yml: No need to install python2 for docs job) #335 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/335 | 11:12 |
| *** valentind has quit IRC | 11:13 | |
| *** jennis has quit IRC | 11:13 | |
| *** jennis has joined #buildstream | 11:15 | |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 11:17 |
| tlater | juergbi: I've addressed your comments on !313: https://gitlab.com/BuildStream/buildstream/merge_requests/313#note_64496989 | 11:18 |
| tlater | Hm, not what I wanted to link, but it'll do the job | 11:18 |
| juergbi | ok, ta | 11:19 |
| gitlab-br-bot | buildstream: merge request (jjardon/no_python2->master: .gitlab-ci.yml: No need to install python2 for docs job) #335 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/335 | 11:33 |
| tristan | juergbi, jmac; if we can land https://gitlab.com/BuildStream/buildstream/merge_requests/318 for UID/GID soon; as it looks very close, then it would be nice to include in 1.1.2; which I may roll out tomorrow... | 11:49 |
| juergbi | yes, that's actually next on my review list | 11:49 |
| juergbi | ah, you already did | 11:49 |
| tristan | I added some comments yeah, whilst I answered your ping there | 11:53 |
| tristan | Honestly, I cant think of a reason to call it `build-uid` and `build-gid` instead of just `uid` and `gid`, but I dont think that is a problem | 11:54 |
| tristan | juergbi, maybe if we had a word which captured the property that the uid/gid is that of the process which will run, it might be more succinct | 11:55 |
| jmac | Thanks tristan, shouldn't take too long to fix those | 11:55 |
| tristan | but then, build-process-uid / build-process-gid, is long and sucks... so I think the current API is fine | 11:55 |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 12:04 |
| gitlab-br-bot | buildstream: merge request (jjardon/copyright->master: Some changes to the copyrigth / author lines) #331 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/331 | 12:11 |
| gitlab-br-bot | buildstream: merge request (jjardon/copyright->master: Some changes to the copyrigth / author lines) #331 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/331 | 12:16 |
| gitlab-br-bot | buildstream: merge request (jjardon/license->master: Add license: Creative Commons Attribution 4.0 International License) #336 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/336 | 12:24 |
| tristan | persia, you may have an opinion on this iirc: https://gitlab.com/BuildStream/buildstream/merge_requests/336 | 12:35 |
| tristan | jjardon[m], since you have been looking at docs, and you are a gitlab kung-fu master, I wonder if you might want to have a look at https://gitlab.com/BuildStream/buildstream/issues/178 | 12:36 |
| gitlab-br-bot | buildstream: issue #306 ("Follow-up from "Some little documentation fixes"") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/306 | 12:37 |
| gitlab-br-bot | buildstream: merge request (jjardon/copyright->master: Some changes to the copyrigth / author lines) #331 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/331 | 12:37 |
| persia | tristan: https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses/ suggests that if anyone contributed docs before code, that would complicate things if the docs were licensed that way. | 12:37 |
| tristan | are our docs properly covered by a specific license yet ? | 12:38 |
| persia | It doesn't explicitly call out LGPL, but that it is one-way with GPL (in that GPLv3 work can become CC-SA work, but CC-SA work cannot be GPLv3) makes me suspicious. | 12:38 |
| tristan | if not, we need to fix it | 12:38 |
| persia | Any docs in the code repo are implicitly covered by the high level code license, but it is best practice to make sure each individual file contains copyright and license declarations. | 12:39 |
| tristan | Also, I wonder if having CC licensed documentation *automatically generated* from LGPL v2.1 source code, is an issue | 12:39 |
| persia | That would not be, any more than using gcc to "automatically generate" a binary imbues the binary with license. | 12:40 |
| persia | Well, at least I have heard that sort of thing. I am not qualified to have an actual opinion :) | 12:40 |
| tristan | the compiler is not a good example | 12:40 |
| persia | How is the docs generator not a compiler? | 12:40 |
| tristan | in this case, the source code contains annotations and code | 12:40 |
| tristan | the annotations are used for documentation, and the code used by python interpretor | 12:41 |
| tristan | but this is both payload/data coming from the *same source code* | 12:41 |
| persia | Right, the "machine code compiler" converts the code to machine code. The "docs generator" converts the annotations to documentation. | 12:41 |
| tristan | right, so I'm talking about the fact that the *source code* itself is LGPL v2.1 licensed | 12:41 |
| tristan | Not sphinx | 12:41 |
| tristan | (which is what generates the docs) | 12:42 |
| persia | I7ve heard arguments both ways. I've read of cases that interpreted it both ways. My preferred interpretation is that this would be an example of one-way LGPLv2.1->GPLv3->CC-SA, which are all documented as being permitted. | 12:42 |
| tristan | Okay, that sounds sensible | 12:43 |
| persia | The problem is that if anyone committed a change to docs, and someone wanted to use that docs change to make a code change, that would go in the wrong direction, so I believe the opinion would be "this imposes additional constraints, which are not permitted" | 12:43 |
| tristan | persia, I think that many months ago in brainstorming, you had a preference for a specific license for non-code "stuff", which is also why I brought it up | 12:43 |
| tristan | tangentially in reply to "best practice to make sure each individual file contains copyright and license declarations": I have only one problem with this, and that is the yaml files; I dont want copyright headers in these | 12:45 |
| persia | I don't recall my preference at the moment, but it might have been CC0 | 12:45 |
| persia | Do you not want copyright headers in YAML because you want to declare them too trivial to copyright, or do you hope to have implicit copyright control over them without headers? | 12:46 |
| tristan | Ok, persia in that case, would you say that it is at least "safe" to apply jjardon[m]'s patch in 178 ? | 12:46 |
| tristan | persia, I would prefer a sweeping statement elsewhere about their copyright, I dont want headers there for a very practical and technical reason | 12:46 |
| tristan | persia, the reason being: We use the yaml files which express defaults for project.conf and plugins... *as documentation* | 12:47 |
| tristan | so we literally include them in docs | 12:47 |
| persia | Am I looking at the wrong thing for 178? I see discussion between you and Sam. | 12:47 |
| tristan | Which is self-documenting and beautiful | 12:47 |
| tristan | oops wrong issue sorry | 12:47 |
| tristan | persia, I mean 336, the link I originally pasted | 12:47 |
| persia | If the YAML files are intended as examples for folk to modify, I would recommend not asserting copyright over them, which typically requires an explicit statement (often in ./COPYING or similar). | 12:48 |
| tristan | They are both code, and documentation; they are not "examples" | 12:48 |
| persia | You can also cc0 the YAML files, but that requires declaration if they are published independent of the archive, which means comments, which you don't want. | 12:48 |
| * persia gets tangled in a maze of little twisty semantics, all alike | 12:49 | |
| tristan | http://buildstream.gitlab.io/buildstream/projectconf.html#project-builtin-defaults <-- this is the default project configuration; *which we load from YAML*, and must be available to read in the docs | 12:49 |
| persia | So, I would not consider merging jjardon's patch in 336 safe, unless the project is prepared to assert that nobody will update the docs in advance of updating code. | 12:50 |
| tristan | http://buildstream.gitlab.io/buildstream/elements/autotools.html#module-elements.autotools <-- this is the documentaiton for the "autotools" element, which expresses it's default configuration | 12:50 |
| persia | Because I have read that CC-SA->GPLv3->LGPLv2.1 are all non-permitted transformations. | 12:50 |
| tristan | persia, would you care to make that comment in the merge request, please ? | 12:51 |
| * persia tries to get gitlab to provide functional authentication tokens | 12:55 | |
| persia | On the YAML files, my recommendation if you don't want to provide licensing, is to add text to COPYING suggesting the content of the YAML files is considered too trivial for copyright to apply, and that the files included in the repository are provided by way of example only. If you are uncomfortable, you may want to get someone qualified to provide better wording: I'm not finding good examples from my searches. | 12:59 |
| persia | It doesn't matter whether they *are* examples, only that the wording of the disclaimer of copyright is correct. | 13:00 |
| persia | http://www.wipo.int/treaties/en/text.jsp?file_id=283698 is the relevant treaty, if someone has questions (as it is important not to pick particular national jurisdictions for the text) | 13:03 |
| * persia is under the impression that "by way of example" is a term of art, but is not actually qualified to confirm that | 13:04 | |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 13:07 |
| jonathanmaw | hrf, I'm stuck trying to figure out why my changes cause the workspace tests to hang (on branch https://gitlab.com/BuildStream/buildstream/tree/214-filter-workspacing-rework) | 13:08 |
| jonathanmaw | I know that if I comment out https://gitlab.com/BuildStream/buildstream/commit/d0e20fd86c6f9fce79de5527860b13f7b7c8b7d1#029d46ba7e1b2197fd4337e31e3d8422a390dad5_619_625 that the CI stops hanging | 13:09 |
| jonathanmaw | but I'm fairly sure I should be calling that (I deferred calling it earlier so that I could initialize the pipeline before defining which elements to track) | 13:10 |
| jonathanmaw | I just can't figure out why the pipeline's hanging | 13:10 |
| juergbi | jonathanmaw: don't know what kind of hang it is but it may be worth rebasing on top of latest master as tristan has fixed a hang yesterday | 13:12 |
| jonathanmaw | ooh | 13:12 |
| juergbi | jonathanmaw: do you see the hang locally as well or only on gitlab? | 13:12 |
| jonathanmaw | juergbi: locally and gitlab | 13:12 |
| juergbi | ok, at least no mysterious CI issue | 13:13 |
| jonathanmaw | but only in local tests, I can't repeat it when I manually invoke buildstream | 13:13 |
| juergbi | right | 13:13 |
| jonathanmaw | juergbi: that's interesting, the tests are failing instead of hanging, now | 13:13 |
| juergbi | yes, it was only hanging due to exceptions | 13:14 |
| juergbi | that should be easier to debug | 13:14 |
| *** xjuan has joined #buildstream | 13:15 | |
| *** tristan has quit IRC | 13:25 | |
| *** tristan has joined #buildstream | 13:28 | |
| gitlab-br-bot | buildstream: merge request (versioned_yaml->master: WIP: Version workspaces.yml) #271 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/271 | 13:30 |
| gitlab-br-bot | buildstream: merge request (jjardon/license->master: docs: Add license: Creative Commons Attribution 4.0 International License) #336 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/336 | 13:37 |
| gitlab-br-bot | buildstream: merge request (jjardon/license->master: docs: Add license: Creative Commons Attribution 4.0 International License) #336 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/336 | 13:40 |
| gitlab-br-bot | buildstream: merge request (jjardon/license->master: docs: Add license: Creative Commons Attribution 4.0 International License) #336 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/336 | 13:42 |
| juergbi | tristan: i almost wrote that comment on !313 as well but i left it out as rewriting the config file is already in master (for the transition from source-based to element-based workspace), so it's not a change introduced by the MR | 13:52 |
| juergbi | i generally agree, though, i don't see a reason | 13:53 |
| jjardon[m] | tristan: sorry I missed you message; I will take a look after work | 13:54 |
| tristan | juergbi, ugh... I already had to submit bugs for the workspaces to not "magically appear" unnecessarily, even when no workspace command was ever run :-/ | 14:21 |
| juergbi | yes, i don't like that either | 14:21 |
| tristan | it would be nice to remove a little more code from that MR, it looks really trivial, especially since it's even less code, and I've had to fend off over-complexity for this tiny patch | 14:22 |
| juergbi | yes, i'm fine with dropping that aspect at the same time | 14:23 |
| * tlater mostly kept it in because nobody had complained about it on skullman's branch, he presumably tried to carry over most of the original MR | 14:24 | |
| gitlab-br-bot | buildstream: merge request (jmac/build-uid-2->master: Sandbox configuration key to specify uid/gid for sandbox) #318 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/318 | 14:25 |
| tlater | Hm, annoying, this means redesigning tests | 14:30 |
| juergbi | ah, interesting point | 14:34 |
| tristan | grrrr | 14:37 |
| tristan | tlater, juergbi this has gone on a long time, and stuff it depending on it | 14:37 |
| tristan | If you want to land it, file a bug with +bug and +refactoring tags about this - it should not be happening. | 14:37 |
| * tlater doesn't think rewriting the tests will take long | 14:38 | |
| tristan | "BuildStream unnecessarily rewrites workspace.yml files" | 14:38 |
| tlater | Almost done with it already, actually | 14:38 |
| tristan | nice :) | 14:38 |
| tlater | It's just a tad annoying because I have to open and close to trigger a conversion... | 14:38 |
| gitlab-br-bot | buildstream: merge request (jmac/build-uid-2->master: Sandbox configuration key to specify uid/gid for sandbox) #318 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/318 | 14:45 |
| *** Prince781 has joined #buildstream | 14:46 | |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 14:51 |
| * tlater hopes that does it, finally | 14:51 | |
| tlater | Gah, stupid newline | 15:05 |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 15:05 |
| tlater | juergbi/tristan: I think !313 should be ready now, don't think the CI will fail again - though I only ran workspace tests offline | 15:13 |
| juergbi | it needs another rebase, though | 15:13 |
| tlater | Master is too quick x) | 15:13 |
| juergbi | tlater: why is the int hack suddenly needed? | 15:15 |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 15:15 |
| tlater | juergbi: I actually cheated a little with the earlier tests, and made some of the asserted ints strs | 15:16 |
| tlater | No longer possible if I want to assert that I have the same thing as the original dict | 15:16 |
| tlater | I know it's ugly, but I can't really think of another way to do it :| | 15:17 |
| tlater | It's a result of the underscore branch's fix. | 15:17 |
| gitlab-br-bot | buildstream: merge request (jmac/build-uid-2->master: Sandbox configuration key to specify uid/gid for sandbox) #318 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/318 | 15:20 |
| tlater | juergbi: Would it be alright to merge despite that hack? I'd be quite sad to have to revert to individual-yet-samey tests here. | 15:27 |
| tlater | I don't expect it to be problematic unless someone writes a very particular test either. | 15:27 |
| juergbi | tlater: wouldn't it be a better alternative to re-read the yaml right after dumping and then use that for comparison? | 15:28 |
| juergbi | i won't argue much here, it's essentially just coding style in a test case | 15:29 |
| juergbi | but trying to convert everything to int seems very wrong | 15:29 |
| tlater | You mean after _yaml.dump()? Gah, I didn't think of that | 15:30 |
| juergbi | yes | 15:30 |
| tlater | Yeah, that's definitely better | 15:30 |
| *** toscalix has quit IRC | 15:35 | |
| *** toscalix has joined #buildstream | 15:37 | |
| *** toscalix has quit IRC | 15:38 | |
| *** toscalix has joined #buildstream | 15:40 | |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 15:42 |
| tlater | juergbi: Awesome :) Still a bit of a hack, but I think this one *cannot* break | 15:42 |
| tlater | Or, at least, if it does _yaml.py has an issue | 15:42 |
| juergbi | set to be merged | 15:45 |
| tlater | \o/ | 15:45 |
| tlater | tyvm juergbi | 15:45 |
| *** toscalix has quit IRC | 15:49 | |
| *** toscalix has joined #buildstream | 15:50 | |
| gitlab-br-bot | buildstream: issue #277 ("workspaces.yaml has no versioning mechanism") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/277 | 15:54 |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: Add versioning to workspaces yaml configuration) #313 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 15:54 |
| gitlab-br-bot | buildstream: merge request (juerg/googlecas->master: WIP: Google CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/337 | 16:03 |
| jonathanmaw | \o/ I figured out why my changes broke everything! | 16:06 |
| jonathanmaw | I think it only worked previously because stuff was already fetched | 16:06 |
| jonathanmaw | I was accidentally marking important sources to be tracked for no good reason | 16:07 |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 16:07 |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 16:20 |
| *** valentind has joined #buildstream | 16:48 | |
| jonathanmaw | \o/ managed to get my implementation working | 16:49 |
| gitlab-br-bot | buildstream: 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/317 | 16:51 |
| gitlab-br-bot | buildstream: issue #305 ("Build failure: "Cache key missing"") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/305 | 16:52 |
| *** xjuan has quit IRC | 16:57 | |
| *** Prince781 has quit IRC | 17:30 | |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 17:31 |
| *** Prince781 has joined #buildstream | 17:41 | |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 17:46 |
| *** toscalix has quit IRC | 17:51 | |
| gitlab-br-bot | buildstream: 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/317 | 17:52 |
| *** dominic has quit IRC | 18:21 | |
| *** ernestask has joined #buildstream | 18:29 | |
| *** tiago has quit IRC | 18:33 | |
| *** aday has quit IRC | 18:40 | |
| *** Prince781 has quit IRC | 18:47 | |
| *** jonathanmaw has quit IRC | 18:48 | |
| *** Prince781 has joined #buildstream | 18:48 | |
| gitlab-br-bot | buildstream: merge request (jmac/exception-hook->master: WIP: Add a handler for otherwise unhandled exceptions in the main BuildStream app) #248 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/248 | 18:50 |
| *** Prince781 has quit IRC | 18:52 | |
| *** Prince781 has joined #buildstream | 18:53 | |
| gitlab-br-bot | buildstream: merge request (jmac/handle-child-complete-exceptions->master: WIP: Handle exceptions in job.child_complete() properly) #240 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/240 | 18:58 |
| *** Prince781 has quit IRC | 19:03 | |
| *** ernestask has quit IRC | 20:05 | |
| *** Prince781 has joined #buildstream | 20:41 | |
| *** Prince781 has quit IRC | 20:49 | |
| *** Prince781 has joined #buildstream | 20:51 | |
| *** tristan has quit IRC | 21:36 | |
| *** Prince781 has quit IRC | 21:48 | |
| *** Prince781 has joined #buildstream | 21:50 | |
| *** Prince781 has quit IRC | 22:04 | |
| *** valentind has quit IRC | 22:15 | |
| *** toscalix has joined #buildstream | 22:54 | |
| *** toscalix has quit IRC | 23:05 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!